当前位置：首页 > news >正文

设计师个人网站主页wordpress 标签类别

news 2025/10/28 10:19:02

设计师个人网站主页,wordpress 标签类别,淮北专业网站建设,网站建设公司擅自关闭客户网络事故现象#xff1a;前端页面返回timeout 事故回溯总结一句话#xff1a; #xff08;1#xff09;因为大KEY调用量#xff0c;随着白天自然流量趋势增长而增长#xff0c;最终在业务高峰最高点期占满带宽使用100%。 #xfeff; #xfeff; #xff08;2#x…事故现象前端页面返回timeout 事故回溯总结一句话 1因为大KEY调用量随着白天自然流量趋势增长而增长最终在业务高峰最高点期占满带宽使用100%。 2从而引发redis的内存使用率在5min之内从0%-100%。 3最终全面GET SET timeout崩溃11点22分02秒。 4最终导致页面返回timeout。未解之谜疑问点内存使用率100% 就等同于redis不可用吗解答正常使用情况下不是。 redis有【缓存淘汰机制】Redis 在内存使用率达到 100% 时不会直接崩溃。相反它依赖内存淘汰策略来释放内存确保系统的稳定性。学习更多24 替换策略缓存满了怎么办 https://time.geekbang.org/column/article/294640 这个配置在哪里大部分同学都是不会主动去调整这里的参数的。因此大概率默认的是volatile-lru 行为使用 LRULeast Recently Used最近最少使用算法驱逐键。volatile-lru 仅驱逐设有过期时间的键allkeys-lru 则驱逐所有键。适用场景缓存场景不介意丢失一些数据。确保你根据实际需求配置适当的内存淘汰策略以便在内存达到上限时系统能够稳定地处理新请求而不会出现写操作失败的情况只要不是noeviction。也就是说照理SET GET都应该没啥问题才对先不考虑其他复杂命令。尽管 Redis 本身不会轻易崩溃但如果内存耗尽且没有淘汰策略或者淘汰策略未能生效Redis 可能拒绝新的写操作并返回错误OOM command not allowed when used memory maxmemory 如果系统的配置或者操作系统的内存管理不当可能会导致 Redis 进程被操作系统杀死。疑问点但是事故现象就是内存使用率100% 时redis不可用怎么解释猜测1会是淘汰不及时导致的性能瓶颈吗也就是说写入的速度淘汰的速度。解答如果是正常的业务写入不可能 redis纯内存淘汰速度是非常快的这个业务特性也并非高频写入这个redis实例其实里面存储的KEY很少最终占了整个实例的内存使用率5%。不太符合正常使用下KEY不断增多最终挤爆内存使用率的问题。因此初步结论Redis 的崩溃一般不会是由于单纯写入速度超过淘汰速度引起的尤其是使用了合理的内存淘汰策略时如果写入速度非常高而淘汰策略无法及时清除旧数据Redis 可能会非常频繁地进行键的查找和淘汰操作从而导致性能下降。 18 波动的响应延迟如何应对变慢的Redis上 https://time.geekbang.org/column/article/286549 具体机制如下过期 key 的自动删除机制。它是 Redis 用来回收内存空间的常用机制应用广泛本身就会引起 Redis 操作阻塞导致性能变慢所以你必须要知道该机制对性能的影响。 Redis 键值对的 key 可以设置过期时间。默认情况下Redis 每 100 毫秒会删除一些过期 key具体的算法如下 1.采样 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 个数的 key并将其中过期的 key 全部删除 2.如果超过 25% 的 key 过期了则重复删除的过程直到过期 key 的比例降至 25% 以下。 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 是 Redis 的一个参数默认是 20那么一秒内基本有 200 个过期 key 会被删除。这一策略对清除过期 key、释放内存空间很有帮助。如果每秒钟删除 200 个过期 key并不会对 Redis 造成太大影响。但是如果触发了上面这个算法的第二条Redis 就会一直删除以释放内存空间。注意删除操作是阻塞的Redis 4.0 后可以用异步线程机制来减少阻塞影响。所以一旦该条件触发Redis 的线程就会一直执行删除这样一来就没办法正常服务其他的键值操作了就会进一步引起其他键值操作的延迟增加Redis 就会变慢。那么算法的第二条是怎么被触发的呢其中一个重要来源就是频繁使用带有相同时间参数的 EXPIREAT 命令设置过期 key这就会导致在同一秒内有大量的 key 同时过期。可以类比JVM频繁GC造成的性能影响。猜测2那就是写入太凶猛且是【非正常业务写入】那到底是什么导致了内存使用率激增呢蛛丝马迹如何解决Redis内存使用率突然升高 https://help.aliyun.com/zh/redis/support/how-to-solve-the-sudden-increase-in-redis-memory-usage?spma2c4g.11186623.0.i12 因此查阅了资料发现最为贴近的答案。证据支撑真相大白果然是这样说明内存是被【缓冲区】挤爆的。 21 缓冲区一个可能引发“惨案”的地方 https://time.geekbang.org/column/article/291277 知识点Redis的内存占用组成使用info memory进行分析我随便模拟了一个缓冲区溢出的case并非事故现场因为当时不会。 # Memoryused_memory:1072693248used_memory_human:1023.99Mused_memory_rss:1090519040used_memory_rss_human:1.02Gused_memory_peak:1072693248used_memory_peak_human:1023.99Mused_memory_peak_perc:100.00%used_memory_overhead:1048576000used_memory_startup:1024000used_memory_dataset:23929848used_memory_dataset_perc:2.23%allocator_allocated:1072693248allocator_active:1090519040allocator_resident:1090519040total_system_memory:16777216000total_system_memory_human:16.00Gused_memory_lua:37888used_memory_lua_human:37.89Kused_memory_scripts:1024000used_memory_scripts_human:1.00Mmaxmemory:1073741824maxmemory_human:1.00Gmaxmemory_policy:noevictionallocator_frag_ratio:1.02allocator_frag_bytes:17825792allocator_rss_ratio:1.00allocator_rss_bytes:0rss_overhead_ratio:1.00rss_overhead_bytes:0mem_fragmentation_ratio:1.02mem_fragmentation_bytes:17825792mem_not_counted_for_evict:0mem_replication_backlog:0mem_clients_slaves:0mem_clients_normal:1048576000mem_aof_buffer:0mem_allocator:jemalloc-5.1.0active_defrag_running:0lazyfree_pending_objects:0 分析和解释从上面的 INFO memory 输出中我们可以看到一些关键信息这些信息表明大部分内存被缓冲区占用殆尽 1.内存使用情况 used_memory: 1072693248 1.02 GB maxmemory: 1073741824 1.00 GB 上面的输出表明当前内存使用几乎达到了配置的最大内存限制内存已接近耗尽。 2.缓冲区占用 used_memory_overhead: 1048576000 1.00 GB 这个值表示 Redis 开销的内存包括缓冲区、连接和其他元数据。在这种情况下大部分 used_memory (1.02 GB) 被 used_memory_overhead (1.00 GB) 占用这意味着大部分内存都被缓冲区等开销占据。 3.数据集占用 used_memory_dataset: 23929848 23.93 MB used_memory_dataset_perc: 2.23% 这里显示实际存储的数据只占了非常少的一部分内存约 23.93 MB而绝大部分内存被缓冲区占据。 4.客户端缓冲区 mem_clients_normal: 1048576000 1.00 GB 这表明普通客户端连接占用了约 1.00 GB 内存这通常意味着输出缓冲区可能已经接近或达到了设定的限制。 5.内存碎片 allocator_frag_ratio: 1.02 mem_fragmentation_ratio: 1.02 碎片率不高表明内存被合理使用但被缓冲区占用过多。总结从上面的例子可以看出Redis 的内存几乎被缓冲区占用殆尽。以下是具体的结论当前内存使用 (used_memory) 已经接近最大内存限制 (maxmemory)即 1.02 GB 接近 1.00 GB 的限制。内存开销 (used_memory_overhead) 很大主要被客户端普通连接使用可能是输出缓冲区而实际的数据仅占用了很少的内存。分配器和 RSS 碎片率 (allocator_frag_ratio 和 mem_fragmentation_ratio) 较低表明碎片不是问题。缓冲内存的理论最大值推导为什么要有缓冲区 Redis工作原理-单客户端视角简单版 Redis工作原理-单客户端视角复杂版缓冲区的功能其实很简单主要就是用一块内存空间来暂时存放命令数据以免出现因为数据和命令的处理速度慢于发送速度而导致的数据丢失和性能问题。因此Redis工作原理-多客户端视角简单版含缓冲区。输入缓冲区定义内存占用输出缓冲区定义内存占用 Redis Server 的输出大小通常是不可控制的。存在bigkey的时候就会产生体积庞大的返回数据。另外也有可能因为执行了太多命令导致产生返回数据的速率超过了往客户端发送的速率导致服务器堆积大量消息从而导致输出缓冲区越来越大占用过多内存甚至导致系统崩溃。Redis 通过设置 client-output-buffer-limit来保护系统安全。不出意外默认是32MB 8MB 60s 对于 Pub/Sub 连接: 硬限制每个 Pub/Sub 客户端连接的输出缓冲区最大可以达到 32MB 。连接池最大连接数300 个连接其中所有连接假设都在处理 Pub/Sub 消息且达到了最大缓冲区限制。故理论上最大输出缓冲区可以达到最大输出缓冲区占用硬限制×连接池最大连接数最大输出缓冲区占用硬限制×连接池最大连接数32MB×3009600MB9.375GB 因此在这种配置下所有 Pub/Sub 连接的输出缓冲区理论上的最大占用内存为 9.375 GB。因此在client-output-buffer-limit是默认的情况下最大占用内存为 9.375 GB。所以MAX输出缓冲区输入缓冲区是否会造成内存使用率100% 当然 MAX输出缓冲区输入缓冲区10.375GB 一个实例的内存规格在本case中是2G 最后的效果就是对象存储的部分因为是有过期时间的过期了自然被清理了。【缓冲内存】↑ 涌入【对象内存】↓ 定时清理并受MAX内存掣肘上限最终的结局Redis 的内存完全被缓冲区占据。自然每当有SET请求进来的时候SET不进来——因为「内存淘汰策略」(maxmemory-policy) 淘汰的是【对象内存】压根起不到作用结论 Redis 的内存完全被缓冲区占据实际上 Redis 将无法正常工作包括数据存储SET 操作和数据读取GET 操作。分析为何缓冲区激增Redis不可用的时间点11:22:02之前都发生了什么知道了缓冲区挤爆Redis内存会导致Redis不工作之后接下来就是分析为何当时出现了缓冲区激增并最终导致redis不可用。实例信息相关代码案件还原 1.自然增长导致流出带宽不断变大直至96MB/s。 2.流出带宽超过96MB/s输出缓冲区内存占用激增甚至溢出 300setMaxTotal*10机器ip数量个客户端之前推导过可以到9G。 3.导致输出缓冲区爆了redis客户端连接不得不关闭。 4.客户端连接关闭后导致请求都走DB。 5.DB走完之后都会执行SET。 6.SET流量飙升且因都是大KEY导致流入带宽激增别看写QPS只有50但是如果每个写都是2MB就可以做到瞬间占满流入带宽。 7.Redis主线程模型处理请求的速度过慢大KEY出现了间歇性阻塞无法及时处理正常发送的请求导致客户端发送的请求在输入缓冲区越积越多。 8.输入缓冲区内存随即激增。 9.最终redis内存被缓冲区内存输入、输出完全侵占。 10.后续的SET GET命令甚至都进不了输入缓冲区阻塞持续到客户端配置的SoTimeout时间但是流入流出带宽依然占据并持续总带宽到达了216MB/s 实例最大带宽192MB/s。 11.造成最终的不可用后续的命令想进场要依赖当前输入缓冲区里的命令被执行给你腾出来位置但是还是那句话Redis主线程处理消化的速度实在是太慢了从图中可以看到Redis的QPS骤降。 11:35分之后我把redis降级了全使用db来抗流量。开发运维规范可以看到Redis的性能是有边界的不能盲目相信所谓的高性能。真正理解性能须使用benchmark。它也是有问题能造成他的性能瓶颈的。计算资源使用通配符、Lua并发、1对多的PUBSUB、热点Key等会大量消耗计算资源集群架构下还会导致访问倾斜无法有效利用所有数据分片。存储资源 Streaming慢消费、大Key等会占用大量存储资源集群架构下还会导致数据倾斜无法有效利用所有数据分片。网络资源扫描全库KEYS命令、大Value、大Key的范围查询如HGETALL命令等会消耗大量的网络资源且极易引发线程阻塞。重要 Redis的高并发能力不等同于高吞吐能力例如将大Value存在Redis里以期望提升访问性能此类场景往往不会有特别大的收益反而会影响Redis整体的服务能力。在上述的事故中就占了【网络资源消耗高】【存储资源消耗高】两大问题因此也到了本文的方法论环节从业务部署、Key的设计、SDK、命令、运维管理等维度展示云数据库Redis开发运维规范业务部署规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis Key设计规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis SDK使用规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis 命令使用规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis 运维管理规范https://help.aliyun.com/zh/redis/use-cases/development-and-o-and-m-standards-for-apsaradb-for-redis 业务部署规范重要程度规范说明 ★★★★★ 确定使用场景为高速缓存或内存数据库。高速缓存建议关闭AOF以降低开销同时由于数据可能会被淘汰业务设计上避免强依赖缓存中的数据。例如Redis被写满后会触发数据淘汰策略以挪移出空间给新的数据写入根据业务的写入量会相应地导致延迟升高。重要如需使用通过数据闪回按时间点恢复数据功能AOF功能需保持开启状态。内存数据库应选购企业版持久内存型支持命令级持久化同时应通过监控报警关注内存使用率。具体操作请参见报警设置。 ★★★★★ 就近部署业务例如将业务部署在同一个专有网络VPC下的ECS实例中。 Redis具备极强的性能如果部署位置过远例如业务服务器与Redis实例通过公网连接网络延迟将极大影响读写性能。说明针对多地部署应用的场景您可以通过全球多活功能借助其提供的跨域复制Geo-replication能力快速实现数据异地灾备和多活降低网络延迟和业务设计的复杂度。更多信息请参见Redis全球多活简介。 ★★★★☆ 为每个业务提供单独的Redis实例。避免业务混用尤其需要避免将同一Redis实例同时用作高速缓存和内存数据库业务。带来的影响例如针对某个业务淘汰策略设置、产生的慢请求或执行FLUSHDB命令影响将扩散至其他业务。 ★★★★☆ 设置合理的过期淘汰策略。云数据库Redis默认的默认逐出策略为 volatile-lru 关于各逐出策略的说明请参见Redis配置参数列表。 ★★★☆☆ 合理控制压测的数据和压测时间。云数据库Redis不会对您压测的数据执行自动删除操作您需要自行控制压测数据的数据量和压测时间避免对业务造成影响。 Key设计规范重要程度规范说明 ★★★★★ 设计合理的Key中Value的大小推荐小于10 KB。过大的Value会引发数据倾斜、热点Key、实例流量或CPU性能被占满等问题应从设计源头上避免此类问题带来的影响。 ★★★★★ 设计合理的Key名称与长度。 Key名称使用可读字符串作为Key名如果使用Key名拼接库、表和字段名时推荐使用英文冒号:分隔。例如project:user:001。在能完整描述业务的前提下尽量简化Key名的长度例如username可简化为u。由于大括号{}为Redis的hash tag语义如果使用的是集群架构的实例Key名称需要正确地使用大括号避免引发数据倾斜更多信息请参见keys-hash-tags。说明集群架构下执行同时操作多个Key的命令时例如RENAME命令如果被操作的Key未使用hash tag让其处于相同的数据分片则命令无法正常执行。长度推荐Key名的长度不超过128字节越短越好。 ★★★★★ 对于支持子Key的复杂数据结构应避免一个Key中包含过多的子Key推荐低于1,000。说明常见的复杂数据结构例如Hash、Set、Zset、Geo、Stream及TairRedis企业版特有的exHash、Bloom、TairGIS等。由于某些命令例如HGETALL的时间复杂度直接与Key中的子Key数量相关。如果频繁执行时间复杂度为O(N)及以上的命令且Key中的子Key数量过多容易引发慢请求、数据倾斜或热点Key问题。 ★★★★☆ 推荐使用串行化方法将Value转变为可读的结构。由于编程语言的字节码随着版本可能会变化如果存储裸对象例如Java Object、C#对象会导致整个软件栈升级困难推荐使用串行化方法将Value变成可读的结构。 SDK使用规范重要程度规范说明 ★★★★★ 推荐使用JedisPool或者JedisCluster连接实例。说明企业版内存型实例推荐使用TairJedis客户端支持新数据结构的封装类。使用方法请参见通过客户端程序连接Redis。如果使用单连接的方式一旦遇到单次超时则无法自动恢复。关于JedisPool的连接方法请参见通过客户端程序连接Redis、JedisPool资源池优化和JedisCluster。 ★★★★☆ 程序客户端需要对超时和慢请求做容错处理。由于Redis服务可能因网络波动或资源占满引发超时或慢请求您需要在程序客户端上设计合理的容错机制。 ★★★★☆ 程序客户端应设置相对宽松的超时重试时间。如果超时重试时间设置的非常短例如200毫秒以下可能引发重试风暴极易引发业务层雪崩。更多信息请参见Redis客户端重连指南。命令使用规范重要程度规范说明 ★★★★★ 避免执行范围查询例如KEYS *使用多次单点查询或SCAN命令来获取延迟优势。执行范围查询可能导致服务发生抖动、引发慢请求或产生阻塞。 ★★★★★ 推荐使用扩展数据结构数据结构模块集成实现复杂功能避免使用Lua脚本。 Lua脚本会占用较多的计算和内存资源且无法被多线程加速过于复杂或不合理的Lua脚本可能导致资源被占满的情况。 ★★★★☆ 合理使用管道pipeline降低链路的往返时延RTTRound-trip time。如果有多个操作命令需要被迅速提交至服务器端且客户端不依赖每个操作返回的结果那么可以通过管道来作为优化性能的批处理工具注意事项如下管道执行期间客户端将独占与服务器端的连接推荐为管道单独建立一个连接将其与常规操作分离。每个管道应包含合理的命令数量不超过100个。 ★★★★☆ 正确使用Redis社区版命令支持。使用事务Transaction时需要注意其限制不同于关系型数据库的事务功能Redis的事务功能不支持回滚Rollback。对于集群架构的实例需要使用hash tag确保命令所要操作的Key都分布在1个Hash槽中同时还需要避免hash tag带来的存储倾斜问题。避免在Lua脚本中封装事务命令可能因编译加载消耗较多的计算资源。 ★★★★☆ 避免使用Redis社区版命令支持执行大量的消息分发工作。由于Pub和Sub不支持数据持久化且不支持ACK应答机制无法实现数据可靠性当执行大量消息分发工作时例如订阅客户端数量超过100且Value超过1 KB订阅客户端可能因服务端资源被占满而无法接收到数据。说明为提升性能和均衡性云数据库Redis对Pub和Sub类命令进行了优化集群架构下代理节点会根据channel name进行Hash计算并分配至对应数据节点。运维管理规范重要程度规范说明 ★★★★★ 充分了解不同的实例管理操作带来的影响。在对Redis实例执行变更配置、重启等操作时实例的状态将发生变化并产生某些影响例如产生秒级的连接闪断在操作前您需要充分了解。更多信息请参见实例状态与影响。 ★★★★★ 验证客户端程序的差错处理能力或容灾逻辑。云数据库Redis支持节点健康状态监测当监测到实例中的主节点不可用时会自动触发主备切换保障实例的高可用性。在客户端程序正式上线前推荐手动触发主备切换可帮助您验证客户端程序的差错处理能力或容灾逻辑。具体操作请参见手动执行主备切换。 ★★★★★ 禁用高耗时或高风险的命令。生产环境中无限制地使用命令可能带来诸多问题例如执行FLUSHALL会直接清空全部数据执行KEYS会阻塞Redis服务。为保障业务稳定、高效率地运行您可以根据实际情况禁用特定的命令具体操作请参见禁用高风险命令。 ★★★★☆ 及时处理阿里云发起的计划内运维操作即待处理事件。为提供更优质的服务持续提升产品性能和稳定性阿里云会不定期地发起计划内运维操作即待处理事件对部分实例所属的机器执行软硬件或网络换代升级例如数据库小版本升级。当您收到来自阿里云的事件通知后您可以查看本次事件的影响根据业务需求评估是否需要调整执行时间。更多信息请参见查看并管理待处理事件。 ★★★★☆ 为核心指标配置监控报警帮助掌握实例运行状态。为CPU使用率、内存使用率、带宽使用率等核心指标配置监控报警实时掌握实例运行状态。具体操作请参见报警设置。 ★★★★☆ 通过云数据库Redis提供的丰富的运维功能定期检查实例状态或辅助排查资源消耗异常问题。分析慢日志帮助您快速找到慢请求问题发生的位置定位发出请求的客户端IP为彻底解决超时问题提供可靠的依据。查看性能监控云数据库Redis支持丰富的性能监控指标帮助您掌握Redis服务的运行状况和进行问题溯源。发起实例诊断帮助您从性能水位、访问倾斜情况、慢日志等多方面评估实例的健康状况快速定位实例的异常情况。发起缓存分析帮助您快速发现实例中的大Key帮助您掌握Key在内存中的占用和分布、Key过期时间等信息。实时Top Key统计帮助您快速发现实例中的热点Key为进一步的优化提供数据支持。 ★★★☆☆ 评估并开启审计日志功能。开通审计日志功能后可记录写操作的审计信息为您提供日志的查询、在线分析、导出等功能助您时刻掌握产品安全及性能情况。更多信息请参见开通审计日志。重要开通审计日志后视写入量或审计量可能会对Redis实例造成5%15%的性能损失。如果业务对Redis实例的写入量非常大建议仅在运维需要例如故障排查期间开通审计功能以免带来性能损失。重点行动项大KEY 大KEY其实并不是长度过长的KEY而是存放了慢查询命令的KEY。对于String类型慢查询的本质在于value的大小。对于其他类型慢查询的本质在于集合的大小时间复杂度带来。如何找到大key 阿里云发现并处理Redis的大Key和热Key https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys?spma2c4g.11186623.0.i1 如何解决大key 其实就是一个字拆。 1.对于字符串类型的key我们通常要在业务层面将value的大小控制在10KB左右如果value确实很大可以考虑采用序列化算法和压缩算法来处理推荐常用的几种序列化算法:Protostuff、Kryo或者Fst。 2.对于集合类型的key我们通常要通过控制集合内元素数量来避免bigKey通常的做法是将一个大的集合类型的key拆分成若干小集合类型的key来达到目的。压测关注点 1.数据是否倾斜不能只看聚合信息要切换到分片上看数据节点 2.是否有大key、热key a.压测过程中关注1CloudDBA-实时TOP KEY统计2CloudDBA-慢请求 b.压测后1CloudDBA-离线全量KEY分析2CloudDBA-诊断报告做到分析报告时间覆盖压测时段 3.CPU使用率、内存使用率、带宽使用率变化趋势流入、流出都要看最好看一个缓存周期 4.如果可以打开审计日志看写入日志是否符合代码逻辑。常用运维命令出线上事故的时候用于快速分析和保留现场。 CLIENT LIST info memory MEMORY USAGE 注本文援引自阿里云开发作者作者看破。
文章转载自：
http://www.morning.sqmbb.cn.gov.cn.sqmbb.cn
http://www.morning.fnhxp.cn.gov.cn.fnhxp.cn
http://www.morning.fdxhk.cn.gov.cn.fdxhk.cn
http://www.morning.kphsp.cn.gov.cn.kphsp.cn
http://www.morning.qfths.cn.gov.cn.qfths.cn
http://www.morning.tntqr.cn.gov.cn.tntqr.cn
http://www.morning.bnfsw.cn.gov.cn.bnfsw.cn
http://www.morning.mdplm.cn.gov.cn.mdplm.cn
http://www.morning.rzczl.cn.gov.cn.rzczl.cn
http://www.morning.btqqh.cn.gov.cn.btqqh.cn
http://www.morning.blbys.cn.gov.cn.blbys.cn
http://www.morning.dwmmf.cn.gov.cn.dwmmf.cn
http://www.morning.jjzbx.cn.gov.cn.jjzbx.cn
http://www.morning.yrms.cn.gov.cn.yrms.cn
http://www.morning.rknhd.cn.gov.cn.rknhd.cn
http://www.morning.4r5w91.cn.gov.cn.4r5w91.cn
http://www.morning.clqpj.cn.gov.cn.clqpj.cn
http://www.morning.fbpdp.cn.gov.cn.fbpdp.cn
http://www.morning.kpxzq.cn.gov.cn.kpxzq.cn
http://www.morning.jpnfm.cn.gov.cn.jpnfm.cn
http://www.morning.zttjs.cn.gov.cn.zttjs.cn
http://www.morning.shinezoneserver.com.gov.cn.shinezoneserver.com
http://www.morning.lfpzs.cn.gov.cn.lfpzs.cn
http://www.morning.nfbxgtj.com.gov.cn.nfbxgtj.com
http://www.morning.wjlrw.cn.gov.cn.wjlrw.cn
http://www.morning.dgpxp.cn.gov.cn.dgpxp.cn
http://www.morning.smtrp.cn.gov.cn.smtrp.cn
http://www.morning.nqnqz.cn.gov.cn.nqnqz.cn
http://www.morning.rlns.cn.gov.cn.rlns.cn
http://www.morning.wglhz.cn.gov.cn.wglhz.cn
http://www.morning.qhvah.cn.gov.cn.qhvah.cn
http://www.morning.pzcjq.cn.gov.cn.pzcjq.cn
http://www.morning.fmjzl.cn.gov.cn.fmjzl.cn
http://www.morning.jjwt.cn.gov.cn.jjwt.cn
http://www.morning.lqgfm.cn.gov.cn.lqgfm.cn
http://www.morning.ejknty.cn.gov.cn.ejknty.cn
http://www.morning.huayaosteel.cn.gov.cn.huayaosteel.cn
http://www.morning.mqlsf.cn.gov.cn.mqlsf.cn
http://www.morning.zqcgt.cn.gov.cn.zqcgt.cn
http://www.morning.zwzwn.cn.gov.cn.zwzwn.cn
http://www.morning.fgxr.cn.gov.cn.fgxr.cn
http://www.morning.ghfmd.cn.gov.cn.ghfmd.cn
http://www.morning.npfkw.cn.gov.cn.npfkw.cn
http://www.morning.tbhf.cn.gov.cn.tbhf.cn
http://www.morning.nfdty.cn.gov.cn.nfdty.cn
http://www.morning.qdsmile.cn.gov.cn.qdsmile.cn
http://www.morning.mxbks.cn.gov.cn.mxbks.cn
http://www.morning.prqdr.cn.gov.cn.prqdr.cn
http://www.morning.dwgcx.cn.gov.cn.dwgcx.cn
http://www.morning.dpflt.cn.gov.cn.dpflt.cn
http://www.morning.ynlpy.cn.gov.cn.ynlpy.cn
http://www.morning.tfrmx.cn.gov.cn.tfrmx.cn
http://www.morning.cnwpb.cn.gov.cn.cnwpb.cn
http://www.morning.qnzld.cn.gov.cn.qnzld.cn
http://www.morning.qcdhg.cn.gov.cn.qcdhg.cn
http://www.morning.mnsmb.cn.gov.cn.mnsmb.cn
http://www.morning.kqyyq.cn.gov.cn.kqyyq.cn
http://www.morning.gchqy.cn.gov.cn.gchqy.cn
http://www.morning.lzdbb.cn.gov.cn.lzdbb.cn
http://www.morning.lqlhw.cn.gov.cn.lqlhw.cn
http://www.morning.ydxwj.cn.gov.cn.ydxwj.cn
http://www.morning.ckhpg.cn.gov.cn.ckhpg.cn
http://www.morning.jsxrm.cn.gov.cn.jsxrm.cn
http://www.morning.wtyqs.cn.gov.cn.wtyqs.cn
http://www.morning.qjxxc.cn.gov.cn.qjxxc.cn
http://www.morning.lsqxh.cn.gov.cn.lsqxh.cn
http://www.morning.mqmxg.cn.gov.cn.mqmxg.cn
http://www.morning.ymwcs.cn.gov.cn.ymwcs.cn
http://www.morning.dsgdt.cn.gov.cn.dsgdt.cn
http://www.morning.fgkrh.cn.gov.cn.fgkrh.cn
http://www.morning.rbnp.cn.gov.cn.rbnp.cn
http://www.morning.mymz.cn.gov.cn.mymz.cn
http://www.morning.cxryx.cn.gov.cn.cxryx.cn
http://www.morning.jycr.cn.gov.cn.jycr.cn
http://www.morning.inheatherskitchen.com.gov.cn.inheatherskitchen.com
http://www.morning.wfzdh.cn.gov.cn.wfzdh.cn
http://www.morning.lzzqz.cn.gov.cn.lzzqz.cn
http://www.morning.tzcr.cn.gov.cn.tzcr.cn
http://www.morning.dycbp.cn.gov.cn.dycbp.cn
http://www.morning.wrbnh.cn.gov.cn.wrbnh.cn

查看全文

http://www.tj-hxxt.cn/news/256400.html