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

哈尔滨开发网站城乡建设部网站第35号令

news 2025/10/23 2:29:16

哈尔滨开发网站,城乡建设部网站第35号令,广告招牌制作设计软件,建官网需要多少钱什么是 Flink 中的状态#xff08;State#xff09;#xff1f; Flink 中的状态是指在 Flink 流处理程序中#xff0c;操作符或函数用于存储和访问数据的机制。状态可以看作是在事件流处理过程中#xff0c;随着时间推移而累积或变更的数据集合。在 Flink 的有状态流处理…什么是 Flink 中的状态State Flink 中的状态是指在 Flink 流处理程序中操作符或函数用于存储和访问数据的机制。状态可以看作是在事件流处理过程中随着时间推移而累积或变更的数据集合。在 Flink 的有状态流处理中状态对于实现复杂的处理逻辑如窗口操作、聚合计算、模式匹配等至关重要。状态使得 Flink 能够在分布式环境中保持计算的连续性和一致性即使在出现故障时也能够通过状态的持久化和恢复来保证数据处理的正确性。 Flink 支持哪两种状态类型 Flink 支持两种状态类型Keyed State 和 Operator State。 Keyed State 当数据流被分区或分片后每个分区上的数据会被分配一个唯一的键Key。Keyed State 是与特定键相关联的状态它为每个键维护一个独立的状态。这种状态类型通常用于需要基于键进行数据聚合或计算的场景例如基于用户ID的点击次数统计。 Operator State 与 Keyed State 不同Operator State 是与并行操作符实例相关的状态而不是与特定的键相关联。这种状态类型在所有并行操作符实例中是共享的通常用于维护全局状态如全局计数器或广播变量。解释一下什么是 Keyed State 和 Operator State。 Keyed State 是一种分区状态它为数据流中的每个键维护一个独立的状态副本。这意味着在有状态的流处理中每个键都会关联一个状态信息并且这个状态信息只与该键相关。Keyed State 使得 Flink 能够在每个键的上下文中独立地进行状态操作如更新、查询等。Keyed State 的常见用例包括基于键的聚合例如计算每个用户的总交易金额。 Operator State 是一种全局状态它属于 Flink 程序中的操作符实例而不是与特定的键相关联。在具有多个并行实例的操作符中每个实例都有自己的 Operator State 副本。这种状态类型适用于需要在操作符的所有并行实例之间共享状态信息的场景例如维护一个全局的计数器或在广播连接中使用。 Flink 中的状态是如何存储的 Flink 中的状态存储是通过状态后端State Backend来实现的。状态后端负责将状态数据持久化到可靠的存储系统中以便在 Flink 作业发生故障时能够从这些状态中恢复。状态后端的选择取决于状态的大小、作业的并行度以及性能要求等因素。状态数据可以存储在以下位置内存对于小状态状态数据可以直接存储在 TaskManager 的内存中。序列化/反序列化状态数据在写入持久化存储之前需要序列化从持久化存储读取时需要反序列化。分布式文件系统如 HDFS用于存储大型状态或作为 Checkpoint 的一部分。本地磁盘RocksDBStateBackend 使用本地磁盘作为状态的存储层适用于处理大规模状态。状态的存储和访问需要考虑性能和一致性Flink 提供了多种状态后端选项来满足不同的存储需求。什么是 Flink 的状态后端State Backend Flink 的状态后端是负责管理 Flink 作业状态的组件。它定义了状态数据如何被存储、访问和恢复。状态后端的选择对 Flink 作业的性能和可靠性有重要影响。Flink 提供了以下几种状态后端 MemoryStateBackend 将状态数据存储在 TaskManager 的内存中。适用于状态较小且对性能要求不高的场景。 FsStateBackend 将状态数据的快照存储在分布式文件系统中如 HDFS。这种方式适用于需要跨多个 TaskManager 共享状态的场景。 RocksDBStateBackend 使用 RocksDB 作为状态的本地存储适用于处理大规模状态数据。RocksDB 将状态数据存储在本地磁盘上并在内存中维护一部分数据的索引以提供快速的状态访问。其他自定义状态后端用户可以根据自己的需求实现自定义的状态后端。状态后端的选择取决于作业的规模、状态的大小、性能要求以及故障恢复的需求。例如对于大规模状态RocksDBStateBackend 可能是更好的选择因为它可以有效地管理大量数据并提供高性能的状态访问。而对于小规模状态MemoryStateBackend 或 FsStateBackend 可能更加简单和高效。比较 MemoryStateBackend、FsStateBackend 和 RocksDBStateBackend 的区别 Flink 提供了三种主要的状态后端来存储和管理状态它们分别是 MemoryStateBackend、FsStateBackend 和 RocksDBStateBackend每种状态后端都有其特点和适用场景 MemoryStateBackend 状态数据存储在内存中访问速度快但受限于 JVM 堆内存的大小。适用于状态数据量较小且对性能要求极高的场景。状态数据不是持久化的如果 TaskManager 失败将会丢失状态数据除非配置了 Checkpoint 进行持久化 FsStateBackend 状态数据的快照存储在分布式文件系统中如 HDFS。支持状态的持久化可以在 TaskManager 失败时从 Checkpoint 恢复状态。适用于需要跨多个 TaskManager 共享状态或状态数据较大的场景。访问速度相对于 MemoryStateBackend 慢因为涉及到 I/O 操作。 RocksDBStateBackend 使用 RocksDB 作为状态的存储RocksDB 是一个基于本地磁盘的嵌入式键值存储适用于处理大规模状态数据RocksDB 可以有效地管理大量数据。状态数据存储在本地磁盘上同时在内存中维护索引以加速状态访问。支持增量 Checkpoint只存储状态变化部分减少 Checkpoint 的开销。如何在 Flink 程序中使用 ValueState ValueState 是 Flink 中的一种状态类型用于存储单个值的状态。在 Flink 程序中使用 ValueState 的步骤如下定义一个 ValueStateDescriptor并指定状态的名称和数据类型。在 RichFunction 类中通过 getRuntimeContext().getState(ValueStateDescriptor) 获取 ValueState 对象。使用 ValueState 对象的 value() 方法获取当前状态值或使用 update(T value) 方法更新状态值。示例代码 public class ExampleFunction extends RichMapFunctionString, String {private transient ValueStateInteger countState; public void open(Configuration config) {ValueStateDescriptorInteger descriptor new ValueStateDescriptor(count, Integer.class); countState getRuntimeContext().getState(descriptor); public String map(String value) throws Exception { int count countState.value(); countState.update(count);return Count: count; } } MapState 与 ListState 有什么不同 MapState 和 ListState 都是 Flink 中的 Keyed State 类型用于存储多个值的状态但它们的存储结构和使用方式有所不同 MapState 存储键值对的集合可以按照键来存取值。适用于需要根据唯一键来索引和更新状态的场景。提供了 put(K key, V value)、get(K key) 和 remove(K key) 等方法来操作状态。 ListState 存储值的列表按照顺序访问和更新。适用于需要维护值的顺序或进行追加操作的场景。提供了 add(T value)、update(int index, T value) 和 get(int index) 等方法来操作状态。如何在 Flink 中实现自定义状态在 Flink 中实现自定义状态通常涉及到以下步骤定义一个状态描述符指定状态的名称和数据类型。在 RichFunction 类中通过 getRuntimeContext().getState(descriptor) 获取状态实例。实现自定义的状态逻辑如状态的初始化、更新和获取。 Flink 状态的生命周期是怎样的 Flink 状态的生命周期与 Flink 作业的生命周期紧密相关主要包括以下几个阶段初始化在 Flink 函数的 open() 方法中状态被初始化此时可以获取状态的引用。运行时在 Flink 函数的 map()、reduce() 等方法中状态被访问和更新。状态的变更在函数执行过程中累积。 Checkpoint 当触发 Checkpoint 时Flink 会将状态的当前值持久化存储到配置的状态后端中。这保证了在发生故障时可以从 Checkpoint 恢复状态。恢复如果 Flink 作业从故障中恢复状态会从最后一次成功的 Checkpoint 中恢复。清理当 Flink 作业取消或完成时相关的状态数据会被清理。对于持久化的状态后端需要确保释放存储资源。状态迁移当作业的并行度发生变化时Flink 会负责状态的迁移确保状态在新的并行实例中正确分配。在整个生命周期中Flink 确保状态的一致性和可靠性同时提供机制来处理状态的持久化和恢复以支持有状态的流处理。 Flink 中的广播状态Broadcast State是如何使用的在 Flink 中广播状态Broadcast State是一种特殊的状态类型它允许将一个流称为广播流的状态广播给另一个流称为主流。这种机制通常用于需要将辅助数据集或维度数据与主数据流进行关联的场景。广播状态的使用方法如下定义广播流首先需要定义一个广播流这个流包含了要广播给主流的状态数据。创建 BroadcastProcessFunction 使用 BroadcastProcessFunction 来接收广播流的状态数据并将其与主流的数据进行关联处理。广播状态的初始化在 BroadcastProcessFunction 的 open() 方法中通过 getRuntimeContext().getBroadcastStateDescriptor(String name) 获取广播状态的描述符并使用它来初始化广播状态。接收和处理广播数据在 processElement 方法中可以通过 getBroadcastState() 方法获取广播状态并根据主流的数据与广播状态进行关联处理。广播状态的更新广播流的状态更新可以通过调用 broadcastState.update(value) 来实现。这些更新会实时广播到所有 BroadcastProcessFunction 实例。处理广播状态的变更在 BroadcastProcessFunction 中可以实现 processBroadcastElement 方法来响应广播状态的变更。 Flink State TTLTime To Live Flink State TTLTime To Live是一种状态管理特性用于定义状态数据的存活时间。启用 TTL 后状态数据在一定时间后会自动过期并被清理从而避免状态数据无限增长有助于管理状态的大小和存储成本。解释 Flink 中的状态 TTL 是什么 Flink 中的状态 TTL 是一种机制它允许开发者为状态设置一个存活时间。当状态数据超过这个时间限制而没有被访问或更新时它将被视为过期并在下一次 Checkpoint 时被清理。状态 TTL 有助于控制状态的大小避免状态数据长时间积累导致内存或存储压力过大。如何为 Flink 的 Keyed State 设置 TTL 为 Flink 的 Keyed State 设置 TTL可以遵循以下步骤定义 TTL 时间确定状态数据的存活时间这个时间可以基于事件时间、处理时间或自定义时间。创建 StateTtlConfig 使用 StateTtlConfig 来配置 TTL 参数包括 TTL 时间、更新类型创建和写入时更新、读写时更新和状态可见性是否返回已过期但未清理的状态。设置状态描述符在创建状态描述符如 ValueStateDescriptor、ListStateDescriptor 等时使用 StateTtlConfig 来设置 TTL 配置。应用 TTL 配置在 Flink 作业的运行时状态后端将根据 TTL 配置自动管理状态的过期和清理。 TTL 在 Flink 状态管理中扮演什么角色 TTL 在 Flink 状态管理中扮演着重要的角色状态大小控制通过 TTL可以限制状态数据的生命周期避免状态无限增长从而控制状态的存储需求。内存和存储优化通过自动清理过期状态TTL 有助于释放内存和存储资源提高资源利用率。提高作业性能减少状态数据量可以降低状态的序列化和反序列化开销提高 Checkpoint 和状态恢复的性能。数据时效性保证在某些场景下状态数据的时效性非常重要TTL 可以确保只有最新的相关状态被保留和处理。简化状态管理 TTL 提供了一种自动的状态清理机制简化了状态管理的复杂性使开发者可以专注于业务逻辑的实现。总之TTL 是 Flink 状态管理中一个非常有用的功能它帮助开发者更有效地控制状态的生命周期优化资源使用并提高作业性能。什么是 Flink 的 Checkpoint 机制 Flink 的 Checkpoint 机制是一种容错机制用于在流处理作业中保存应用程序的状态以便在发生故障时能够从故障点恢复。Checkpoint 通过周期性地对 Flink 作业的状态进行快照来实现。这些快照包含了作业中所有有状态操作符的状态信息可以是内存中的键控状态Keyed State或操作符状态Operator State。当启用 Checkpoint 机制时JobManager 会协调各个 TaskManager 进行状态的保存。状态信息会保存到之前配置的状态后端State Backend例如内存、文件系统或 RocksDB 等。在 Checkpoint 完成之后如果作业失败Flink 可以通过最后一次成功的 Checkpoint 来恢复作业的状态和位置。 Flink 的 Checkpoint 有哪些触发方式 Flink 的 Checkpoint 可以通过以下几种方式触发定期触发配置一个固定的间隔时间每隔这个时间间隔自动触发一次 Checkpoint。事件驱动触发基于处理的事件数量或处理的记录条数来触发 Checkpoint例如每处理一定数量的记录后触发。外部触发通过 Flink 的外部接口或管理界面手动触发 Checkpoint。条件触发基于特定条件来触发 Checkpoint如当某个并发修改操作符的状态达到一定大小时触发。屏障Barrier触发 Flink 使用一种特殊的记录称为 Barrier来对齐不同并行操作符的 Checkpoint。当所有输入通道的 Barrier 都到达一个操作符时该操作符就可以进行 Checkpoint。解释一下 Flink 的 Exactly-Once 语义是如何通过 Checkpoint 实现的。 Flink 的 Exactly-Once 语义确保了即使在故障发生的情况下流处理作业也能以一致的状态精确地处理每条记录一次。这是通过以下步骤实现的两阶段提交协议 Flink 使用两阶段提交2PC协议来确保在分布式系统中状态的一致性。在第一阶段协调者JobManager请求所有参与者TaskManager准备提交 Checkpoint并保存当前状态的副本。在第二阶段如果所有参与者都成功准备协调者会通知参与者提交状态否则会进行回滚。状态保存在 Checkpoint 过程中状态被保存到持久化存储中。Flink 支持多种状态后端如内存、文件系统或 RocksDB这些后端负责将状态数据写入到可靠的存储中。故障恢复在故障发生时Flink 会从最近的 Checkpoint 中恢复状态。如果是在 Checkpoint 完成之后处理的记录Flink 会从故障点继续处理确保不会有记录丢失。端到端的一致性 Flink 还与外部系统如 Kafka集成确保在 Checkpoint 时这些系统的消费偏移量也一并保存。这样在恢复时Flink 可以通知这些系统从保存的偏移量开始发送数据从而实现端到端的 Exactly-Once 语义。如何配置 Flink 的 Checkpoint 间隔 Flink 的 Checkpoint 间隔可以通过 Flink 作业的配置参数进行设置配置文件在 flink-conf.yaml 文件中设置 state.checkpoint.interval 参数以定义自动触发 Checkpoint 的时间间隔。编程配置在 Flink 作业的执行环境中使用 StreamExecutionEnvironment 的 setCheckpointInterval(long interval) 方法来设置 Checkpoint 间隔。命令行在启动 Flink 作业时通过命令行参数 --checkpointing.interval 来指定 Checkpoint 间隔。动态修改在 Flink Web UI 中可以在作业运行时动态地修改 Checkpoint 间隔。 Flink 的 Checkpoint 会对性能有哪些影响 Checkpoint 机制虽然提供了容错能力但也可能对 Flink 作业的性能产生影响处理延迟 Checkpoint 的过程中需要等待 Barrier 对齐这可能会增加处理延迟。 I/O 开销状态数据需要从内存写入到持久化存储中这涉及到 I/O 操作可能会影响性能。网络传输在分布式系统中Barrier 和状态数据可能需要在网络中传输这会增加网络负载。资源竞争 Checkpoint 过程中可能会与其他作业或任务竞争资源如 CPU、内存和存储。状态大小状态数据的大小直接影响 Checkpoint 的开销。大型状态的 Checkpoint 会占用更多的时间和资源。恢复时间在作业恢复时需要从 Checkpoint 中恢复状态这可能需要一定的时间特别是对于大型状态。为了减少 Checkpoint 对性能的影响可以采取以下措施优化状态大小避免不必要的状态存储。选择合适的状态后端以减少 I/O 开销。调整 Checkpoint 间隔平衡容错和性能。使用增量 Checkpoint 或异步 Checkpoint 来减少性能损失。在资源充足的环境中运行 Flink 作业以降低资源竞争的影响。 Flink 是如何实现容错的 Flink 实现容错主要依赖于其有状态的计算模型和 Checkpoint 机制。以下是 Flink 实现容错的关键步骤有状态计算 Flink 允许操作符持有状态这些状态可以是键控状态Keyed State或操作符状态Operator State。状态使得 Flink 能够在流处理过程中记住中间结果。 Checkpoint 机制 Flink 定期地对操作符的状态进行快照这些快照称为 Checkpoint。Checkpoint 被保存到持久化存储中以便在发生故障时可以从这些 Checkpoint 恢复状态。 Barrier 对齐 Flink 使用 Barrier 来确保在 Checkpoint 过程中数据流中的所有操作符都在相同的时间点进行状态保存。这保证了数据的一致性防止了在 Checkpoint 过程中数据的乱序。端到端的一致性 Flink 与外部系统的集成如 Kafka保证了在 Checkpoint 时消费的偏移量也一并保存。这样在恢复时Flink 可以通知外部系统从保存的偏移量开始发送数据。故障恢复当作业失败时Flink 会从最近的 Checkpoint 恢复状态并从故障点继续处理数据。如果是精确一次Exactly-Once处理语义的作业Flink 会确保在恢复时不会有数据丢失或重复处理。两阶段提交协议对于需要端到端一致性的作业Flink 使用两阶段提交协议来确保 Checkpoint 的原子性防止在 Checkpoint 过程中发生故障导致的数据不一致。解释一下 Flink 的重启策略。 Flink 的重启策略定义了作业在失败时如何重启以及重启的条件。以下是 Flink 支持的几种重启策略固定延迟重启策略Fixed Delay Restart Strategy 在这种策略下作业在失败后会等待一个固定的时间间隔然后重启。如果作业继续失败它会无限期地重启或者直到达到最大重启次数。故障率重启策略Failure Rate Restart Strategy 这种策略根据作业的故障率来决定是否重启。如果故障率超过了设定的阈值作业将不会重启。无重启策略No Restart Strategy 作业在失败后不会尝试重启。后备重启策略Fallback Restart Strategy 这是一种组合策略首先尝试固定延迟重启如果失败再尝试故障率重启。自定义重启策略开发者可以自定义重启策略根据作业的特定需求来实现重启逻辑。重启策略可以通过 Flink 的配置参数或编程方式设置以适应不同的作业需求和容错要求。 Flink 的端到端end-to-end一致性是如何保证的 Flink 的端到端一致性是通过以下机制保证的状态一致性 Flink 通过 Checkpoint 机制确保所有操作符的状态在全局一致的时间点被保存。数据一致性使用 Barrier 对齐确保数据流在 Checkpoint 时的一致性防止数据乱序。两阶段提交协议对于需要端到端一致性的作业Flink 使用两阶段提交协议来确保 Checkpoint 的原子性。外部系统集成 Flink 与外部系统的集成如 Kafka通过保存和恢复消费偏移量来确保数据的一致性。幂等操作对于外部系统的更新操作Flink 可以通过幂等操作来保证即使在重试或恢复时也不会导致数据不一致。事务性数据源 Flink 支持事务性数据源这些数据源可以在 Checkpoint 时保存其读取位置确保在恢复时能够从正确的位置读取数据。 Flink 的故障恢复机制有哪些 Flink 的故障恢复机制包括 Checkpoint 恢复在作业失败时Flink 可以从最近的 Checkpoint 恢复状态并从故障点继续处理。作业重启 Flink 可以根据配置的重启策略在作业失败后自动重启作业。数据重放对于需要精确一次处理语义的作业Flink 可以从数据源如 Kafka重放数据以确保没有数据丢失或重复。状态迁移当作业的并行度变化时Flink 可以迁移状态到新的并行实例。端到端的一致性保证通过与外部系统的集成Flink 可以在恢复时从正确的位置继续处理数据。自定义恢复逻辑开发者可以实现自定义的恢复逻辑以适应特定的业务需求。 Flink 如何处理分布式快照中的不一致性问题 Flink 使用分布式快照算法Chandy-Lamport 算法来处理分布式快照中的不一致性问题 Barrier 对齐 Flink 通过 Barrier 对齐确保在 Checkpoint 时所有操作符都在相同的时间点保存状态从而避免不一致性。 Checkpoint 协调 JobManager 作为 Checkpoint 的协调者负责触发 Checkpoint 并确保所有参与的操作符都完成了状态保存。状态保存点每个操作符在接收到 Barrier 后会将当前的状态保存到一个保存点这个保存点是 Checkpoint 的一部分。本地状态清除在 Checkpoint 完成后操作符会清除本地状态以避免状态的不一致性。全局 Commit 当所有操作符都成功保存了状态JobManager 会通知所有操作符提交 Checkpoint这是一个全局的 Commit 操作。故障恢复如果在 Checkpoint 过程中发生故障Flink 会从上一个成功的 Checkpoint 恢复丢弃当前不一致的 Checkpoint。端到端的一致性通过两阶段提交协议和与外部系统的集成Flink 确保了分布式快照的全局一致性。通过这些机制Flink 能够处理分布式快照中的不一致性问题并确保了作业的容错性和数据的一致性。 Flink 状态在并行度变化时如何迁移 Flink 在并行度变化时例如当用户增加或减少作业的并行实例以应对负载变化时状态的迁移是必不可少的。Flink 的状态迁移过程如下状态的划分当并行度变化时现有状态需要根据新的并行度进行重新划分。Flink 会根据新旧并行度的比例来分配状态给新的操作符实例。全量迁移在某些情况下如从并行度 1 扩展到更大的并行度可能需要进行全量迁移即所有状态都需要重新分配。部分迁移如果并行度变化不大Flink 可能只对部分状态进行迁移以减少迁移的开销。重新分配操作 Flink 会在内部执行重新分配操作这可能涉及到网络传输将状态数据从一个 TaskManager 传输到另一个。状态一致性在整个迁移过程中Flink 确保状态的一致性使用 Barrier 来对齐状态确保在状态迁移期间数据的完整性。作业暂停在某些情况下Flink 可能需要暂停作业以进行状态迁移以确保状态的准确性和一致性。状态后端的支持不同的状态后端如 MemoryStateBackend、FsStateBackend、RocksDBStateBackend对状态迁移的支持程度不同某些状态后端可能更适合处理大规模状态的迁移。解释一下 Flink 的状态重分配机制。 Flink 的状态重分配机制是指在作业的并行度发生变化时Flink 自动重新分配状态数据到新的并行实例的机制。以下是状态重分配的关键点状态的重新分片 Flink 会根据新的并行度对现有状态进行重新分片确保每个新的并行实例都能获得一部分状态。状态访问的协调在状态重分配过程中Flink 会协调对状态的访问以避免并发问题。状态后端的作用状态后端在状态重分配中扮演重要角色它负责存储和检索状态数据支持高效的重分配操作。网络传输状态重分配可能涉及到状态数据的网络传输特别是在分布式部署的 Flink 集群中。作业的动态特性状态重分配是 Flink 作业动态特性的一部分允许作业根据资源和负载的变化调整并行度。容错性状态重分配机制需要确保即使在重分配过程中发生故障作业也能从 Checkpoint 中恢复。性能考虑状态重分配可能会对性能产生影响因此 Flink 会尝试优化重分配过程减少对作业性能的影响。如何优化 Flink 状态的迁移和重分配优化 Flink 状态的迁移和重分配可以通过以下方法选择合适的状态后端根据作业的特性和资源环境选择合适的状态后端以支持高效的状态迁移。减少状态大小优化状态数据的结构和存储方式减少状态的大小以降低迁移的开销。使用增量 Checkpoint 如果使用 RocksDBStateBackend可以利用增量 Checkpoint 来减少状态迁移的数据量。并行化状态迁移在可能的情况下并行化状态迁移过程以提高迁移效率。优化网络传输优化网络传输例如通过压缩状态数据或使用高速网络以减少迁移时间。状态本地化尽可能将状态迁移限制在本地避免跨节点迁移以减少网络传输的开销。合理配置并行度合理规划作业的并行度避免频繁的并行度变化以减少状态迁移的需要。使用 Flink 的 Savepoint 通过 Savepoint 进行状态的版本控制和迁移可以在不同版本的 Flink 或作业之间迁移状态。
文章转载自：
http://www.morning.wnbqy.cn.gov.cn.wnbqy.cn
http://www.morning.dfkby.cn.gov.cn.dfkby.cn
http://www.morning.phlrp.cn.gov.cn.phlrp.cn
http://www.morning.ksgjy.cn.gov.cn.ksgjy.cn
http://www.morning.zzbwjy.cn.gov.cn.zzbwjy.cn
http://www.morning.kgjyy.cn.gov.cn.kgjyy.cn
http://www.morning.kllzy.com.gov.cn.kllzy.com
http://www.morning.kpfds.cn.gov.cn.kpfds.cn
http://www.morning.yngtl.cn.gov.cn.yngtl.cn
http://www.morning.fywqr.cn.gov.cn.fywqr.cn
http://www.morning.fbmjw.cn.gov.cn.fbmjw.cn
http://www.morning.fllfc.cn.gov.cn.fllfc.cn
http://www.morning.klzdy.cn.gov.cn.klzdy.cn
http://www.morning.rykn.cn.gov.cn.rykn.cn
http://www.morning.lsnnc.cn.gov.cn.lsnnc.cn
http://www.morning.jhrlk.cn.gov.cn.jhrlk.cn
http://www.morning.bpkqd.cn.gov.cn.bpkqd.cn
http://www.morning.lwyqd.cn.gov.cn.lwyqd.cn
http://www.morning.srcth.cn.gov.cn.srcth.cn
http://www.morning.fksrg.cn.gov.cn.fksrg.cn
http://www.morning.wyfpc.cn.gov.cn.wyfpc.cn
http://www.morning.hqgxz.cn.gov.cn.hqgxz.cn
http://www.morning.gfqjf.cn.gov.cn.gfqjf.cn
http://www.morning.prddj.cn.gov.cn.prddj.cn
http://www.morning.jsphr.cn.gov.cn.jsphr.cn
http://www.morning.ykgp.cn.gov.cn.ykgp.cn
http://www.morning.rymb.cn.gov.cn.rymb.cn
http://www.morning.tmfhx.cn.gov.cn.tmfhx.cn
http://www.morning.wkqrp.cn.gov.cn.wkqrp.cn
http://www.morning.lxqkt.cn.gov.cn.lxqkt.cn
http://www.morning.ohmyjiu.com.gov.cn.ohmyjiu.com
http://www.morning.wmhlz.cn.gov.cn.wmhlz.cn
http://www.morning.cwrnr.cn.gov.cn.cwrnr.cn
http://www.morning.kgslc.cn.gov.cn.kgslc.cn
http://www.morning.cyhlq.cn.gov.cn.cyhlq.cn
http://www.morning.pqnps.cn.gov.cn.pqnps.cn
http://www.morning.yxlhz.cn.gov.cn.yxlhz.cn
http://www.morning.rfhmb.cn.gov.cn.rfhmb.cn
http://www.morning.wdykx.cn.gov.cn.wdykx.cn
http://www.morning.bflws.cn.gov.cn.bflws.cn
http://www.morning.qlpq.cn.gov.cn.qlpq.cn
http://www.morning.lqytk.cn.gov.cn.lqytk.cn
http://www.morning.fesiy.com.gov.cn.fesiy.com
http://www.morning.rcmwl.cn.gov.cn.rcmwl.cn
http://www.morning.xbxks.cn.gov.cn.xbxks.cn
http://www.morning.bpmtz.cn.gov.cn.bpmtz.cn
http://www.morning.bpncd.cn.gov.cn.bpncd.cn
http://www.morning.wfwqr.cn.gov.cn.wfwqr.cn
http://www.morning.rsfp.cn.gov.cn.rsfp.cn
http://www.morning.qpxrr.cn.gov.cn.qpxrr.cn
http://www.morning.jcfdk.cn.gov.cn.jcfdk.cn
http://www.morning.sgmis.com.gov.cn.sgmis.com
http://www.morning.fwrr.cn.gov.cn.fwrr.cn
http://www.morning.bktly.cn.gov.cn.bktly.cn
http://www.morning.jcrfm.cn.gov.cn.jcrfm.cn
http://www.morning.mwwnz.cn.gov.cn.mwwnz.cn
http://www.morning.pwghp.cn.gov.cn.pwghp.cn
http://www.morning.tbknh.cn.gov.cn.tbknh.cn
http://www.morning.pjwfs.cn.gov.cn.pjwfs.cn
http://www.morning.dfrenti.com.gov.cn.dfrenti.com
http://www.morning.iznek.com.gov.cn.iznek.com
http://www.morning.pffx.cn.gov.cn.pffx.cn
http://www.morning.cdrzw.cn.gov.cn.cdrzw.cn
http://www.morning.hjjkz.cn.gov.cn.hjjkz.cn
http://www.morning.wjyyg.cn.gov.cn.wjyyg.cn
http://www.morning.swwpl.cn.gov.cn.swwpl.cn
http://www.morning.rxlck.cn.gov.cn.rxlck.cn
http://www.morning.mjtgt.cn.gov.cn.mjtgt.cn
http://www.morning.fmrrr.cn.gov.cn.fmrrr.cn
http://www.morning.rdtq.cn.gov.cn.rdtq.cn
http://www.morning.wxckm.cn.gov.cn.wxckm.cn
http://www.morning.xblrq.cn.gov.cn.xblrq.cn
http://www.morning.bfycr.cn.gov.cn.bfycr.cn
http://www.morning.fbfnk.cn.gov.cn.fbfnk.cn
http://www.morning.fssmx.com.gov.cn.fssmx.com
http://www.morning.fgtls.cn.gov.cn.fgtls.cn
http://www.morning.cyysq.cn.gov.cn.cyysq.cn
http://www.morning.qdbcd.cn.gov.cn.qdbcd.cn
http://www.morning.fxxmj.cn.gov.cn.fxxmj.cn
http://www.morning.dxqfh.cn.gov.cn.dxqfh.cn

查看全文

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