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

ftp 上传网站iis网站没有属性

news 2025/11/3 13:48:21

ftp 上传网站,iis网站没有属性,网站策划设计,山东济南网络公司目录 1、事务的发展 2、本地事务 #xff08;1#xff09;如何保障原子性和持久性#xff1f; #xff08;2#xff09;如何保障隔离性#xff1f; 2、全局事务 #xff08;1#xff09;XA事务的两段式提交 #xff08;2#xff09;XA事务的三段式提交…目录 1、事务的发展 2、本地事务 1如何保障原子性和持久性 2如何保障隔离性 2、全局事务 1XA事务的两段式提交 2XA事务的三段式提交 3、分布式事务 1CAP定理 2如何保证最终一致性 3TCC事务冻结资源 4SAGA事务补偿资源 1、事务的发展我们都知道数据库中事务的“ACID”特性但事务的概念今天已经有所延伸不再局限于数据库本身了。所有需要保证数据一致性的应用场景包括但不限于数据库、事务内存、缓存、消息队列、分布式存储等等都有可能用到事务。当一个服务只使用一个数据源时通过 A、I、D 来获得一致性是最经典的做法也是相对容易的。此时多个并发事务所读写的数据能够被数据源感知是否存在冲突并发事务的读写在时间线上的最终顺序是由数据源来确定的这种事务间一致性被称为“内部一致性”。// C是最终结果当一个服务使用到多个不同的数据源甚至多个不同服务同时涉及多个不同的数据源时问题就变得困难了许多。此时并发执行甚至是先后执行的多个事务在时间线上的顺序并不由任何一个数据源来决定这种涉及多个数据源的事务间一致性被称为“外部一致性”。//外部一致性少了一个统一的数据源去协调一致性所以我们需要模拟内部一致性的实现去创造一个统一的外部的协调器 2、本地事务本地事务是指仅操作单一事务资源的、不需要全局事务管理器进行协调的事务。本地事务是一种最基础的事务解决方案只适用于单个服务使用单个数据源的场景。从应用角度看它是直接依赖于数据源本身提供的事务能力来工作的在程序代码层面最多只能对事务接口做一层标准化的包装如JDBC接口并不能深入参与到事务的运作过程中事务的开启、终止、提交、回滚、嵌套、设置隔离级别乃至与应用代码贴近的事务传播方式全部都要依赖底层数据源的支持才能工作这一点与后续介绍的XA、TCC、SAGA等主要靠应用程序代码来实现的事务有着十分明显的区别。//程序不介入单一事物源的操作那么传统统数据库管理系统是如何通过ACID来实现事务的 1如何保障原子性和持久性实现原子性和持久性的最大困难是“写入磁盘”这个操作并不是原子的不仅有“写入”与“未写入”状态还客观存在着“正在写”的中间状态。由于写入中间状态与崩溃都不可能消除所以如果不做额外保障措施的话将内存中的数据写入磁盘并不能保证原子性与持久性。解决方式是使用日志。以日志的形式——即以仅进行顺序追加的文件写入的形式这是最高效的写入方式先记录到磁盘中。//顺序写只有在日志记录全部安全落盘数据库在日志中看到代表事务成功提交的“提交记录”Commit Record后才会根据日志上的信息对真正的数据进行修改修改完成后再在日志中加入一条“结束记录”End Record表示事务已完成持久化这种事务实现方法被称为“提交日志”Commit Logging。//MySQL中提交日志的两段式提交-redoLog 你以为问题就此解决了吗NO单一的提交日志会带来性能问题。 Commit Logging存在一个巨大的先天缺陷所有对数据的真实修改都必须发生在事务提交以后即日志写入了 Commit Record 之后。在此之前即使磁盘 I/O 有足够空闲即使某个事务修改的数据量非常庞大占用了大量的内存缓冲区无论何种理由都决不允许在事务提交之前就修改磁盘上的数据这一点是Commit Logging成立的前提却对提升数据库的性能十分不利。为此ARIES 提出了“提前写入日志”Write-Ahead Logging的日志改进方案所谓“提前写入”Write-Ahead就是允许在事务提交之前写入变动数据的意思。//预写日志但是如果事务提交前就有部分变动数据写入磁盘那一旦事务要回滚或者发生了崩溃这些提前写入的变动数据就都成了错误。又如何去避免这个问题呢给出的解决办法是增加了另一种被称为 Undo Log 的日志类型当变动数据写入磁盘前必须先记录Undo Log注明修改了哪个位置的数据、从什么值改成什么值等以便在事务回滚或者崩溃恢复时根据 Undo Log 对提前写入的数据变动进行擦除。//增加回滚日志 2如何保障隔离性隔离性保证了每个事务各自读、写的数据互相独立不会彼此影响。只从定义上就能嗅出隔离性肯定与并发密切相关因为如果没有并发所有事务全都是串行的那就不需要任何隔离。那么要如何在并发下实现串行的数据访问呢答案就是加锁同步现代数据库均提供了以下三种锁写锁排他锁如果数据有加写锁就只有持有写锁的事务才能对数据进行写入操作数据加持着写锁时其他事务不能写入数据也不能施加读锁。读锁共享锁多个事务可以对同一个数据添加多个读锁数据被加上读锁后就不能再被加上写锁所以其他事务不能对该数据进行写入但仍然可以读取。对于持有读锁的事务如果该数据只有它自己一个事务加了读锁则允许直接将其升级为写锁然后写入数据。范围锁对于某个范围直接加排他锁在这个范围内的数据不能被写入。请注意“范围不能被写入”与“一批数据不能被写入”的差别即不要把范围锁理解成一组排他锁的集合。加了范围锁后不仅不能修改该范围内已有的数据也不能在该范围内新增或删除任何数据后者是一组排他锁的集合无法做到的。并发控制Concurrency Control理论决定了隔离程度与并发能力是相互抵触的隔离程度越高并发访问时的吞吐量就越低。加锁就是进行串行化数据库不考虑性能肯定是不行的所以数据库中如何去权衡隔离性和吞吐量呢这里就要说到我们常见的数据库隔离级别了即“串行化”“可重复度”幻读问题“读已提交”不可重复读问题“读未提交”脏读问题。//四种隔离级别 “可重复度”会产生幻读问题原因是可重复读没有范围锁来禁止在该范围内插入新的数据这是一个事务受到其他事务影响隔离性被破坏的表现。//缺乏范围锁 “读已提交”对事务涉及的数据加的写锁会一直持续到事务结束但加的读锁在查询操作完成后会马上释放。因为缺乏贯穿整个事务周期的读锁无法禁止读取过的数据发生变化所以会出现不可重复读问题。//缺乏贯穿整个事务周期的读锁 “读未提交”会产生脏读问题。原因在于它只会对事务涉及的数据加写锁且一直持续到事务结束但完全不加读锁。//完全无读锁不加锁也就不会去获取锁总结以上三种问题幻读、不可重复读、脏读等问题都是由于一个事务在读数据的过程中受另外一个写数据的事务影响而破坏了隔离性。//都是“一个事务读另一个事务写”的隔离问题 “多版本并发控制”Multi-Version Concurrency ControlMVCC无锁优化方案 MVCC是一种读取优化策略它的“无锁”特指读取时不需要加锁。MVCC的基本思路是对数据库的任何修改都不会直接覆盖之前的数据而是产生一个新版本与老版本共存以此达到读取时可以完全不加锁的目的。//使用版本快照——不加读锁可实现读已提交和可重复读两种隔离级别也就是说使用MVCC既保证了可重复读的隔离性又具备了读未提交的性能。需要注意的是MVCC是只针对“读写”场景的优化如果是两个事务同时修改数据即“写写”的情况那就没有多少优化的空间了此时加锁几乎是唯一可行的解决方案。 2、全局事务在本节里全局事务被限定为一种适用于单个服务使用多个数据源场景的事务解决方案。 1XA事务的两段式提交 1991年为了解决分布式事务的一致性问题X/Open组织提出了一套名为X/Open XAXA是 eXtended Architecture 的缩写的处理事务架构其核心内容是定义了全局的事务管理器Transaction Manager用于协调全局事务和局部的资源管理器Resource Manager用于驱动本地事务之间的通信接口。//XA架构 XA 接口是双向的能在一个事务管理器和多个资源管理器之间形成通信桥梁通过协调多个数据源的一致动作实现全局事务的统一提交或者统一回滚。 XA将事务提交拆分成两阶段准备阶段又叫作投票阶段在这一阶段协调者询问事务的所有参与者是否准备好提交参与者如果已经准备好提交则回复 Prepared否则回复 Non-Prepared。准备操作是在重做日志中记录全部事务提交操作所要做的内容它与本地事务中真正提交的区别只是暂不写入最后一条Commit Record而已。//重量操作提交阶段又叫作执行阶段协调者如果在上一阶段收到所有事务参与者回复的 Prepared 消息则先自己在本地持久化事务状态为 Commit然后向所有参与者发送 Commit 指令让所有参与者立即执行提交操作否则协调者将在自己完成事务状态为Abort持久化后向所有参与者发送Abort指令让参与者立即执行回滚操作。这个阶段的提交操作应是很轻量的仅仅是持久化一条Commit Record而已通常能够快速完成只有收到Abort指令时才需要根据回滚日志清理已提交的数据这可能是相对重负载操作。//轻量操作两段式提交原理简单并不难实现但有几个非常显著的缺点 1单点问题协调者在两段式提交中具有举足轻重的作用。一旦宕机所有参与者都会受到影响。如果协调者一直没有恢复那所有参与者都必须一直等待。 2性能问题在两段式提交过程中所有参与者相当于被绑定为一个统一调度的整体期间要经过两次远程服务调用三次数据持久化整个过程将持续到参与者集群中最慢的那一个处理操作结束为止这决定了两段式提交的性能通常都较差。//一个慢所有都慢 3一致性风险尽管提交阶段时间很短但这仍是一段明确存在的危险期如果协调者在发出准备指令后根据收到各个参与者发回的信息确定事务状态是可以提交的协调者会先持久化事务状态并提交自己的事务如果这时候网络忽然断开无法再通过网络向所有参与者发出Commit指令的话就会导致部分数据协调者的已提交但部分数据参与者的未提交且没有办法回滚产生数据不一致的问题。//提交阶段断网 2XA事务的三段式提交为了缓解两段式提交协议的一部分缺陷具体地说是协调者的单点问题和准备阶段的性能问题后续又发展出了“三段式提交”3 Phase Commit3PC协议。//在两阶段提交的基础上增加询问阶段增加事务成功率三段式提交把原本的两段式提交的准备阶段再细分为两个阶段分别称为 CanCommit、PreCommit把提交阶段改称为 DoCommit 阶段。其中新增的 CanCommit 是一个询问阶段即协调者让每个参与的数据库根据自身状态评估该事务是否有可能顺利完成。将准备阶段一分为二的理由是这个阶段是重负载的操作一旦协调者发出开始准备的消息每个参与者都将马上开始写重做日志它们所涉及的数据资源即被锁住如果此时某一个参与者宣告无法完成提交相当于大家都做了一轮无用功。所以增加一轮询问阶段如果都得到了正面的响应那事务能够成功提交的把握就比较大了这也意味着因某个参与者提交时发生崩溃而导致大家全部回滚的风险相对变小。因此在事务需要回滚的场景中三段式提交的性能通常要比两段式提交好很多但在事务能够正常提交的场景中两者的性能都很差甚至三段式因为多了一次询问还要稍微更差一些。//减少回滚风险同样也是由于事务失败回滚概率变小在三段式提交中如果在 PreCommit 阶段之后发生了协调者宕机即参与者没有等到 DoCommit 的消息的话默认的操作策略将是提交事务而不是回滚事务或者持续等待这就相当于避免了协调者单点问题的风险。//避免单点问题三段式提交对单点问题和回滚时的性能问题有所改善但是对一致性风险问题并未有任何改进甚至是略有增加的。譬如进入PreCommit阶段之后协调者发出的指令不是 Ack 而是Abort而此时因网络问题有部分参与者直至超时都未能收到协调者的 Abort 指令的话这些参与者将会错误地提交事务这就产生了不同参与者之间数据不一致的问题。//三段式并没有减少一致性风险 //探究Spring 事务的传播级别是否可以解决多个数据源的事务呢 3、分布式事务本节所说的分布式事务Distributed Transaction特指多个服务同时访问多个数据源的事务处理机制。为什么 XA 的事务机制分布式环境中不好用了呢这需要从 CAP 与 ACID 的矛盾说起。 1CAP定理 CAP定理Consistency、Availability、Partition Tolerance Theorem描述了在一个分布式系统中涉及共享数据问题时以下三个特性最多只能同时满足其中两个一致性Consistency代表数据在任何时刻、任何分布式节点中所看到的都是符合预期的。可用性Availability代表系统不间断地提供服务的能力。分区容忍性Partition Tolerance代表分布式环境中部分节点因网络原因而彼此失联后即与其他节点形成“网络分区”时系统仍能正确地提供服务的能力。由于 CAP 定理已有严格的证明那么接下来直接分析舍弃 C、A、P 时所带来的不同影响。 1如果放弃分区容忍性CA without P意味着我们将假设节点之间的通信永远是可靠的。永远可靠的通信在分布式系统中必定是不成立的这不是你想不想的问题而是只要用到网络来共享数据分区现象就始终存在。//在分布式系统中不成立 2如果放弃可用性CP without A意味着我们将假设一旦网络发生分区节点之间的信息同步时间可以无限制地延长。在现实中选择放弃可用性的情况一般出现在对数据质量要求很高的场合中除了 DTP 模型的分布式数据库事务外著名的HBase也属于 CP 系统。 3如果放弃一致性AP without C意味着我们将假设一旦发生分区节点之间所提供的数据可能不一致。选择放弃一致性的 AP 系统是目前设计分布式系统的主流选择因为 P 是分布式网络的天然属性你再不想要也无法丢弃而 A 通常是建设分布式的目的如果可用性随着节点数量增加反而降低的话很多分布式系统可能就失去了存在的价值除非银行、证券这些涉及金钱交易的服务宁可中断也不能出错否则多数系统是不能容忍节点越多可用性反而越低的。//主流方案那么问题来了“事务”原本的目的就是获得“一致性”而在分布式环境中“一致性”却不得不成为通常被牺牲、被放弃的那一项属性。如何解决这个矛盾呢无论如何我们建设信息系统终究还是要确保操作结果至少在最终交付的时候是正确的这句话的意思是允许数据在中间过程出错不一致但应该在输出时被修正过来。为此人们又重新给一致性下了定义将前面我们在 CAP、ACID 中讨论的一致性称为“强一致性”Strong Consistency而把牺牲了 C 的 AP 系统又要尽可能获得正确结果的行为称为追求“弱一致性”。// 换一种思路思考问题保证正确性 - 非常聪明的想法技术都是妥协创新出来的在弱一致性里人们又总结出了一种稍微强一点的特例被称为“最终一致性”Eventual Consistency它是指如果数据在一段时间之内没有被另外的操作更改那它最终会达到与强一致性过程相同的结果。 2如何保证最终一致性最终一致性的概念来源于 BASE 理论。BASE 分别是基本可用性Basically Available、柔性事务Soft State和最终一致性Eventually Consistent的缩写。 BASE 理论为实现最终一致性提供了一种非常有价值的分布式事务解决思路那就是“可靠事件队列”就简单的理解为消息中间件好了本质上差不多。 “可靠事件队列”是依靠持续重试来保证可靠性的解决方案它在计算机的其他领域中已被频繁使用也有了专门的名字——“最大努力交付”Best-Effort Delivery譬如 TCP 协议中未收到 ACK 应答自动重新发包的可靠性保障就属于最大努力交付。而可靠事件队列还有一种更普通的形式被称为“最大努力一次提交”Best-Effort 1PC指的是将最有可能出错的业务以本地事务的方式完成后采用不断重试的方式来促使同一个分布式事务中的其他关联业务全部完成。//不断重试幂等性 3TCC事务冻结资源可靠消息队列虽然能保证最终结果的相对可靠性但整个过程完全没有任何隔离性可言虽然在一些业务中隔离性是无关紧要的但在有些业务中缺乏隔离性就会带来许多麻烦比如“超售”的问题。// 消息队列无法保证隔离性所以如果业务需要隔离那通常就应该重点考虑 TCC 方案该方案天生适用于需要强隔离性的分布式事务中。 TCC 是另一种常见的分布式事务机制它是 “Try-Confirm-Cancel” 三个单词的缩写它分为以下三个阶段 Try尝试执行阶段完成所有业务可执行性的检查保障一致性并且预留好全部需要用到的业务资源保障隔离性。Confirm确认执行阶段不进行任何业务检查直接使用 Try 阶段准备的资源来完成业务处理。Confirm阶段可能会重复执行因此本阶段执行的操作需要具备幂等性。Cancel取消执行阶段释放 Try 阶段预留的业务资源。Cancel 阶段可能会重复执行因此本阶段执行的操作也需要具备幂等性。 //在持续重试的模式下会发送重复的消息所以幂等性很重要。 TCC 其实有点类似 2PC 的准备阶段和提交阶段但 TCC 是在用户代码层面而不是在基础设施层面这为它的实现带来了较高的灵活性可以根据需要设计资源锁定的粒度。//业务侵入式较强的事务方案 TCC 在业务执行时只操作预留资源几乎不会涉及锁和资源的争用具有很高的性能潜力。但是TCC也带来了更高的开发成本和业务侵入性即更高的开发成本和更换事务实现方案的替换成本所以通常我们并不会完全靠裸编码来实现 TCC而是基于某些分布式事务中间件譬如阿里开源的 Seata去完成尽量减轻一些编码工作量。 4SAGA事务补偿资源 TCC 事务具有较强的隔离性避免了“超售”的问题而且其性能一般来说是本篇提及的几种柔性事务模式中最高的但它仍不能满足所有的场景。TCC 的业务侵入性很强并不是所有的资源都可以让你去 Try比如尝试冻结银行余额所以 TCC 中的第一步 Try 阶段往往无法施行。//不是所有的资源都可以去冻结因此只能考虑采用另外一种柔性事务方案SAGA 事务。SAGA 在英文中是“长篇故事、长篇记叙、一长串事件”的意思。//长时间事务所谓“长时间事务”Long Lived Transaction就是把一个大事务分解为可以交错运行的一系列子事务集合。原本 SAGA 的目的是避免大事务长时间锁定数据库的资源后来才发展成将一个分布式环境中的大事务分解为一系列本地事务的设计模式。//分解事务——再一次使用拆分思想 SAGA 由两部分操作组成阶段一将大事务拆分成若干个小事务将整个分布式事务 T 分解为 n 个子事务命名为 T1T2…Ti…Tn。每个子事务都应该是或者能被视为原子行为。如果分布式事务能够正常提交其对数据的影响即最终一致性应与连续按顺序成功提交 Ti 等价。为每一个子事务设计对应的补偿动作命名为C1C2…Ci…Cn。Ti 与 Ci 必须满足以下条件。 Ti 与 Ci 都具备幂等性。Ti 与 Ci 满足交换律Commutative即无论先执行 Ti 还是先执行 Ci其效果都是一样的。Ci 必须能成功提交即不考虑 Ci 本身提交失败被回滚的情形如出现就必须持续重试直至成功或者被人工介入为止。 // 拆分事务设计事务补偿动作如果 T1 到 Tn 均成功提交那事务顺利完成否则要采取以下两种恢复策略之一。阶段二正向恢复Forward Recovery如果 Ti 事务提交失败则一直对 Ti 进行重试直至成功为止最大努力交付。这种恢复方式不需要补偿适用于事务最终都要成功的场景譬如在别人的银行账号中扣了款就一定要给别人发货。正向恢复的执行模式为T1T2…Ti失败Ti重试…Ti1…Tn。//无需补偿反向恢复Backward Recovery如果 Ti 事务提交失败则一直执行 Ci 对 Ti 进行补偿直至成功为止最大努力交付。这里要求 Ci 必须在持续重试后执行成功。反向恢复的执行模式为T1T2…Ti失败Ci补偿…C2C1。//不断执行补偿直至成功与 TCC 相比SAGA 不需要为资源设计冻结状态和撤销冻结的操作补偿操作往往要比冻结操作容易实现得多。譬如账号余额直接在银行维护的场景从银行划转货款到业务系统中这步是经由用户支付操作来促使银行提供服务如果后续业务操作失败尽管我们无法要求银行撤销之前的用户转账操作但是由业务系统将货款转回到用户账号上作为补偿措施却是完全可行的。 SAGA 必须保证所有子事务都得以提交或者补偿但 SAGA 系统本身也有可能会崩溃所以它必须设计成与数据库类似的日志机制被称为 SAGA Log以保证系统恢复后可以追踪到子事务的执行情况譬如执行至哪一步或者补偿至哪一步了。另外尽管补偿操作通常比冻结/撤销容易实现但保证正向、反向恢复过程严谨地进行也需要花费不少工夫譬如通过服务编排、可靠事件队列等方式完成所以SAGA 事务通常也不会直接靠裸编码来实现一般是在事务中间件的基础上完成前面提到的 Seata 就同样支持 SAGA 事务模式。//实现复杂依赖框架声明上述文字为阅读周志明先生《凤凰架构》一书的读书笔记大部分内容为书中摘要。
文章转载自：
http://www.morning.ntwfr.cn.gov.cn.ntwfr.cn
http://www.morning.rlbc.cn.gov.cn.rlbc.cn
http://www.morning.wsyst.cn.gov.cn.wsyst.cn
http://www.morning.cwlxs.cn.gov.cn.cwlxs.cn
http://www.morning.khtyz.cn.gov.cn.khtyz.cn
http://www.morning.nggry.cn.gov.cn.nggry.cn
http://www.morning.hpspr.com.gov.cn.hpspr.com
http://www.morning.zcyxq.cn.gov.cn.zcyxq.cn
http://www.morning.qqbjt.cn.gov.cn.qqbjt.cn
http://www.morning.hyxwh.cn.gov.cn.hyxwh.cn
http://www.morning.crkhd.cn.gov.cn.crkhd.cn
http://www.morning.tkrdg.cn.gov.cn.tkrdg.cn
http://www.morning.rxgnn.cn.gov.cn.rxgnn.cn
http://www.morning.jnhhc.cn.gov.cn.jnhhc.cn
http://www.morning.ljdjn.cn.gov.cn.ljdjn.cn
http://www.morning.plhyc.cn.gov.cn.plhyc.cn
http://www.morning.wpcfm.cn.gov.cn.wpcfm.cn
http://www.morning.yqgbw.cn.gov.cn.yqgbw.cn
http://www.morning.nba1on1.com.gov.cn.nba1on1.com
http://www.morning.bxrqf.cn.gov.cn.bxrqf.cn
http://www.morning.pwdgy.cn.gov.cn.pwdgy.cn
http://www.morning.qxgmp.cn.gov.cn.qxgmp.cn
http://www.morning.lgnz.cn.gov.cn.lgnz.cn
http://www.morning.zqcgt.cn.gov.cn.zqcgt.cn
http://www.morning.bhrbr.cn.gov.cn.bhrbr.cn
http://www.morning.kjlhb.cn.gov.cn.kjlhb.cn
http://www.morning.swsrb.cn.gov.cn.swsrb.cn
http://www.morning.zxxys.cn.gov.cn.zxxys.cn
http://www.morning.gcspr.cn.gov.cn.gcspr.cn
http://www.morning.jrbyz.cn.gov.cn.jrbyz.cn
http://www.morning.gzzxlp.com.gov.cn.gzzxlp.com
http://www.morning.nlqgb.cn.gov.cn.nlqgb.cn
http://www.morning.pwmm.cn.gov.cn.pwmm.cn
http://www.morning.pffx.cn.gov.cn.pffx.cn
http://www.morning.gbhsz.cn.gov.cn.gbhsz.cn
http://www.morning.bnrff.cn.gov.cn.bnrff.cn
http://www.morning.rzdzb.cn.gov.cn.rzdzb.cn
http://www.morning.czlzn.cn.gov.cn.czlzn.cn
http://www.morning.tmsxn.cn.gov.cn.tmsxn.cn
http://www.morning.leyuhh.com.gov.cn.leyuhh.com
http://www.morning.lsfzq.cn.gov.cn.lsfzq.cn
http://www.morning.hhkzl.cn.gov.cn.hhkzl.cn
http://www.morning.hphfy.cn.gov.cn.hphfy.cn
http://www.morning.rwzmz.cn.gov.cn.rwzmz.cn
http://www.morning.jgzmr.cn.gov.cn.jgzmr.cn
http://www.morning.rdxnt.cn.gov.cn.rdxnt.cn
http://www.morning.fygbq.cn.gov.cn.fygbq.cn
http://www.morning.nkrmh.cn.gov.cn.nkrmh.cn
http://www.morning.hrpjx.cn.gov.cn.hrpjx.cn
http://www.morning.tscsd.cn.gov.cn.tscsd.cn
http://www.morning.cptzd.cn.gov.cn.cptzd.cn
http://www.morning.wmpw.cn.gov.cn.wmpw.cn
http://www.morning.znsyn.cn.gov.cn.znsyn.cn
http://www.morning.cgthq.cn.gov.cn.cgthq.cn
http://www.morning.yqgny.cn.gov.cn.yqgny.cn
http://www.morning.yrnyz.cn.gov.cn.yrnyz.cn
http://www.morning.lmqw.cn.gov.cn.lmqw.cn
http://www.morning.ypzsk.cn.gov.cn.ypzsk.cn
http://www.morning.qkqzm.cn.gov.cn.qkqzm.cn
http://www.morning.pmghz.cn.gov.cn.pmghz.cn
http://www.morning.fbnsx.cn.gov.cn.fbnsx.cn
http://www.morning.gppqf.cn.gov.cn.gppqf.cn
http://www.morning.ltywr.cn.gov.cn.ltywr.cn
http://www.morning.rbnj.cn.gov.cn.rbnj.cn
http://www.morning.pghfy.cn.gov.cn.pghfy.cn
http://www.morning.xhhqd.cn.gov.cn.xhhqd.cn
http://www.morning.glxdk.cn.gov.cn.glxdk.cn
http://www.morning.klrpm.cn.gov.cn.klrpm.cn
http://www.morning.fdrch.cn.gov.cn.fdrch.cn
http://www.morning.lgznc.cn.gov.cn.lgznc.cn
http://www.morning.fhrt.cn.gov.cn.fhrt.cn
http://www.morning.fglyb.cn.gov.cn.fglyb.cn
http://www.morning.nggry.cn.gov.cn.nggry.cn
http://www.morning.dmxzd.cn.gov.cn.dmxzd.cn
http://www.morning.jkwwm.cn.gov.cn.jkwwm.cn
http://www.morning.jgzmr.cn.gov.cn.jgzmr.cn
http://www.morning.gjssk.cn.gov.cn.gjssk.cn
http://www.morning.ttfh.cn.gov.cn.ttfh.cn
http://www.morning.sbpt.cn.gov.cn.sbpt.cn
http://www.morning.wjlrw.cn.gov.cn.wjlrw.cn

查看全文

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