义县城乡建设局网站,福州网站设计哪里建站,免费的网络电视app,网站建设研究的意义秒杀系统要如何设计#xff1f; 前言
高并发下如何设计秒杀系统#xff1f;这是一个高频面试题。这个问题看似简单#xff0c;但是里面的水很深#xff0c;它考查的是高并发场景下#xff0c;从前端到后端多方面的知识。
秒杀一般出现在商城的促销活动中#xff0c;指定…秒杀系统要如何设计 前言
高并发下如何设计秒杀系统这是一个高频面试题。这个问题看似简单但是里面的水很深它考查的是高并发场景下从前端到后端多方面的知识。
秒杀一般出现在商城的促销活动中指定了一定数量比如10个的商品比如手机以极低的价格比如0.1元让大量用户参与活动但只有极少数用户能够购买成功。这类活动商家绝大部分是不赚钱的说白了是找个噱头宣传自己。
虽说秒杀只是一个促销活动但对技术要求不低。下面给大家总结一下设计秒杀系统需要注意的9个细节。 1 瞬时高并发
一般在秒杀时间点比如12点前几分钟用户并发量才真正突增达到秒杀时间点时并发量会达到顶峰。
但由于这类活动是大量用户抢少量商品的场景必定会出现狼多肉少的情况所以其实绝大部分用户秒杀会失败只有极少部分用户能够成功。
正常情况下大部分用户会收到商品已经抢完的提醒收到该提醒后他们大概率不会在那个活动页面停留了如此一来用户并发量又会急剧下降。所以这个峰值持续的时间其实是非常短的这样就会出现瞬时高并发的情况下面用一张图直观的感受一下流量的变化 像这种瞬时高并发的场景传统的系统很难应对我们需要设计一套全新的系统。可以从以下几个方面入手
页面静态化CDN加速缓存mq异步处理限流分布式锁
2. 页面静态化
活动页面是用户流量的第一入口所以是并发量最大的地方。
如果这些流量都能直接访问服务端恐怕服务端会因为承受不住这么大的压力而直接挂掉。 活动页面绝大多数内容是固定的比如商品名称、商品描述、图片等。为了减少不必要的服务端请求通常情况下会对活动页面做静态化处理。用户浏览商品等常规操作并不会请求到服务端。只有到了秒杀时间点并且用户主动点了秒杀按钮才允许访问服务端。 这样能过滤大部分无效请求。
但只做页面静态化还不够因为用户分布在全国各地有些人在北京有些人在成都有些人在深圳地域相差很远网速各不相同。
如何才能让用户最快访问到活动页面呢
这就需要使用CDN它的全称是Content Delivery Network即内容分发网络。 使用户就近获取所需内容降低网络拥塞提高用户访问响应速度和命中率。
3 秒杀按钮
大部分用户怕错过秒杀时间点一般会提前进入活动页面。此时看到的秒杀按钮是置灰不可点击的。只有到了秒杀时间点那一时刻秒杀按钮才会自动点亮变成可点击的。
但此时很多用户已经迫不及待了通过不停刷新页面争取在第一时间看到秒杀按钮的点亮。
从前面得知该活动页面是静态的。那么我们在静态页面中如何控制秒杀按钮只在秒杀时间点时才点亮呢
没错使用js文件控制。
为了性能考虑一般会将css、js和图片等静态资源文件提前缓存到CDN上让用户能够就近访问秒杀页面。
看到这里有些聪明的小伙伴可能会问CDN上的js文件是如何更新的
秒杀开始之前js标志为false还有另外一个随机参数。 当秒杀开始的时候系统会生成一个新的js文件此时标志为true并且随机参数生成一个新值然后同步给CDN。由于有了这个随机参数CDN不会缓存数据每次都能从CDN中获取最新的js代码。 此外前端还可以加一个定时器控制比如10秒之内只允许发起一次请求。如果用户点击了一次秒杀按钮则在10秒之内置灰不允许再次点击等到过了时间限制又允许重新点击该按钮。
4 读多写少
在秒杀的过程中系统一般会先查一下库存是否足够如果足够才允许下单写数据库。如果不够则直接返回该商品已经抢完。
由于大量用户抢少量商品只有极少部分用户能够抢成功所以绝大部分用户在秒杀时库存其实是不足的系统会直接返回该商品已经抢完。
这是非常典型的读多写少 的场景。 如果有数十万的请求过来同时通过数据库查缓存是否足够此时数据库可能会挂掉。因为数据库的连接资源非常有限比如mysql无法同时支持这么多的连接。
而应该改用缓存比如redis。
即便用了redis也需要部署多个节点。
5 缓存问题
通常情况下我们需要在redis中保存商品信息里面包含商品id、商品名称、规格属性、库存等信息同时数据库中也要有相关信息毕竟缓存并不完全可靠。
用户在点击秒杀按钮请求秒杀接口的过程中需要传入的商品id参数然后服务端需要校验该商品是否合法。
大致流程如下图所示 根据商品id先从缓存中查询商品如果商品存在则参与秒杀。如果不存在则需要从数据库中查询商品如果存在则将商品信息放入缓存然后参与秒杀。如果商品不存在则直接提示失败。
这个过程表面上看起来是OK的但是如果深入分析一下会发现一些问题。
5.1 缓存击穿
比如商品A第一次秒杀时缓存中是没有数据的但数据库中有。虽说上面有如果从数据库中查到数据则放入缓存的逻辑。
然而在高并发下同一时刻会有大量的请求都在秒杀同一件商品这些请求同时去查缓存中没有数据然后又同时访问数据库。结果悲剧了数据库可能扛不住压力直接挂掉。
如何解决这个问题呢
这就需要加锁最好使用分布式锁。 当然针对这种情况最好在项目启动之前先把缓存进行预热。即事先把所有的商品同步到缓存中这样商品基本都能直接从缓存中获取到就不会出现缓存击穿的问题了。
是不是上面加锁这一步可以不需要了
表面上看起来确实可以不需要。但如果缓存中设置的过期时间不对缓存提前过期了或者缓存被不小心删除了如果不加速同样可能出现缓存击穿。
其实这里加锁相当于买了一份保险。
5.2 缓存穿透
如果有大量的请求传入的商品id在缓存中和数据库中都不存在这些请求不就每次都会穿透过缓存而直接访问数据库了。
由于前面已经加了锁所以即使这里的并发量很大也不会导致数据库直接挂掉。
但很显然这些请求的处理性能并不好有没有更好的解决方案
这时可以想到布隆过滤器。 系统根据商品id先从布隆过滤器中查询该id是否存在如果存在则允许从缓存中查询数据如果不存在则直接返回失败。
虽说该方案可以解决缓存穿透问题但是又会引出另外一个问题布隆过滤器中的数据如何更缓存中的数据保持一致
这就要求如果缓存中数据有更新则要及时同步到布隆过滤器中。如果数据同步失败了还需要增加重试机制而且跨数据源能保证数据的实时一致性吗
显然是不行的。
所以布隆过滤器绝大部分使用在缓存数据更新很少的场景中。
如果缓存数据更新非常频繁又该如何处理呢
这时就需要把不存在的商品id也缓存起来。 下次再有该商品id的请求过来则也能从缓存中查到数据只不过该数据比较特殊表示商品不存在。需要特别注意的是这种特殊缓存设置的超时时间应该尽量短一点。
6 库存问题
对于库存问题看似简单实则里面还是有些东西。
真正的秒杀商品的场景不是说扣完库存就完事了如果用户在一段时间内还没完成支付扣减的库存是要加回去的。
所以在这里引出了一个预扣库存的概念预扣库存的主要流程如下 扣减库存中除了上面说到的预扣库存和回退库存之外还需要特别注意的是库存不足和库存超卖问题。
6.1 数据库扣减库存
使用数据库扣减库存是最简单的实现方案了假设扣减库存的sql如下
update product set stockstock-1 where id123;这种写法对于扣减库存是没有问题的但如何控制库存不足的情况下不让用户操作呢
这就需要在update之前先查一下库存是否足够了。
伪代码如下
int stock mapper.getStockById(123);
if(stock 0) {int count mapper.updateStock(123);if(count 0) {addOrder(123);}
}
大家有没有发现这段代码的问题
没错查询操作和更新操作不是原子性的会导致在并发的场景下出现库存超卖的情况。
有人可能会说这样好办加把锁不就搞定了比如使用synchronized关键字。
确实可以但是性能不够好。
还有更优雅的处理方案即基于数据库的乐观锁这样会少一次数据库查询而且能够天然的保证数据操作的原子性。
只需将上面的sql稍微调整一下
update product set stockstock-1 where idproduct and stock 0;
在sql最后加上stock 0就能保证不会出现超卖的情况。
但需要频繁访问数据库我们都知道数据库连接是非常昂贵的资源。在高并发的场景下可能会造成系统雪崩。而且容易出现多个请求同时竞争行锁的情况造成相互等待从而出现死锁的问题。
6.2 redis扣减库存
redis的incr方法是原子性的可以用该方法扣减库存。伪代码如下 boolean exist redisClient.query(productId,userId);if(exist) {return -1;}int stock redisClient.queryStock(productId);if(stock 0) {return 0;}redisClient.incrby(productId, -1);redisClient.add(productId,userId);
return 1;
代码流程如下
先判断该用户有没有秒杀过该商品如果已经秒杀过则直接返回-1。查询库存如果库存小于等于0则直接返回0表示库存不足。如果库存充足则扣减库存然后将本次秒杀记录保存起来。然后返回1表示成功。
估计很多小伙伴一开始都会按这样的思路写代码。但如果仔细想想会发现这段代码有问题。
有什么问题呢
如果在高并发下有多个请求同时查询库存当时都大于0。由于查询库存和更新库存非原则操作则会出现库存为负数的情况即库存超卖。
当然有人可能会说加个synchronized不就解决问题
调整后代码如下 boolean exist redisClient.query(productId,userId);if(exist) {return -1;}synchronized(this) {int stock redisClient.queryStock(productId);if(stock 0) {return 0;}redisClient.incrby(productId, -1);redisClient.add(productId,userId);}return 1;
加synchronized确实能解决库存为负数问题但是这样会导致接口性能急剧下降每次查询都需要竞争同一把锁显然不太合理。
为了解决上面的问题代码优化如下
boolean exist redisClient.query(productId,userId);
if(exist) {return -1;
}
if(redisClient.incrby(productId, -1)0) {return 0;
}
redisClient.add(productId,userId);
return 1;
该代码主要流程如下
先判断该用户有没有秒杀过该商品如果已经秒杀过则直接返回-1。扣减库存判断返回值是否小于0如果小于0则直接返回0表示库存不足。如果扣减库存后返回值大于或等于0则将本次秒杀记录保存起来。然后返回1表示成功。
该方案咋一看好像没问题。
但如果在高并发场景中有多个请求同时扣减库存大多数请求的incrby操作之后结果都会小于0。
虽说库存出现负数不会出现超卖的问题。但由于这里是预减库存如果负数值负的太多的话后面万一要回退库存时就会导致库存不准。
那么有没有更好的方案呢
6.3 lua脚本扣减库存
我们都知道lua脚本是能够保证原子性的它跟redis一起配合使用能够完美解决上面的问题。
lua脚本有段非常经典的代码 StringBuilder lua new StringBuilder();lua.append(if (redis.call(exists, KEYS[1]) 1) then);lua.append( local stock tonumber(redis.call(get, KEYS[1])););lua.append( if (stock -1) then);lua.append( return 1;);lua.append( end;);lua.append( if (stock 0) then);lua.append( redis.call(incrby, KEYS[1], -1););lua.append( return stock;);lua.append( end;);lua.append( return 0;);lua.append(end;);lua.append(return -1;);
该代码的主要流程如下
先判断商品id是否存在如果不存在则直接返回。获取该商品id的库存判断库存如果是-1则直接返回表示不限制库存。如果库存大于0则扣减库存。如果库存等于0是直接返回表示库存不足。
7 分布式锁
之前我提到过在秒杀的时候需要先从缓存中查商品是否存在如果不存在则会从数据库中查商品。如果数据库中则将该商品放入缓存中然后返回。如果数据库中没有则直接返回失败。
大家试想一下如果在高并发下有大量的请求都去查一个缓存中不存在的商品这些请求都会直接打到数据库。数据库由于承受不住压力而直接挂掉。
那么如何解决这个问题呢
这就需要用redis分布式锁了。
7.1 setNx加锁
使用redis的分布式锁首先想到的是setNx命令。
if (jedis.setnx(lockKey, val) 1) {jedis.expire(lockKey, timeout);
}
用该命令其实可以加锁但和后面的设置超时时间是分开的并非原子操作。
假如加锁成功了但是设置超时时间失败了该lockKey就变成永不失效的了。在高并发场景中该问题会导致非常严重的后果。
那么有没有保证原子性的加锁命令呢
7.2 set加锁
使用redis的set命令它可以指定多个参数。
String result jedis.set(lockKey, requestId, NX, PX, expireTime);
if (OK.equals(result)) {return true;
}
return false;
其中
lockKey锁的标识requestId请求idNX只在键不存在时才对键进行设置操作。PX设置键的过期时间为 millisecond 毫秒。expireTime过期时间
由于该命令只有一步所以它是原子操作。
7.3 释放锁
接下来有些朋友可能会问在加锁时既然已经有了lockKey锁标识为什么要需要记录requestId呢
答requestId是在释放锁的时候用的。
if (jedis.get(lockKey).equals(requestId)) {jedis.del(lockKey);return true;
}
return false;
在释放锁的时候只能释放自己加的锁不允许释放别人加的锁。
这里为什么要用requestId用userId不行吗
答如果用userId的话假设本次请求流程走完了准备删除锁。此时巧合锁到了过期时间失效了。而另外一个请求巧合使用的相同userId加锁会成功。而本次请求删除锁的时候删除的其实是别人的锁了。
当然使用lua脚本也能避免该问题
if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1])
else return 0
end
它能保证查询锁是否存在和删除锁是原子操作。
7.4 自旋锁
上面的加锁方法看起来好像没有问题但如果你仔细想想如果有1万的请求同时去竞争那把锁可能只有一个请求是成功的其余的9999个请求都会失败。
在秒杀场景下会有什么问题
答每1万个请求有1个成功。再1万个请求有1个成功。如此下去直到库存不足。这就变成均匀分布的秒杀了跟我们想象中的不一样。
如何解决这个问题呢
答使用自旋锁。
try {Long start System.currentTimeMillis();while(true) {String result jedis.set(lockKey, requestId, NX, PX, expireTime);if (OK.equals(result)) {return true;}long time System.currentTimeMillis() - start;if (timetimeout) {return false;}try {Thread.sleep(50);} catch (InterruptedException e) {e.printStackTrace();}}} finally{unlock(lockKey,requestId);
}
return false;
在规定的时间比如500毫秒内自旋不断尝试加锁如果成功则直接返回。如果失败则休眠50毫秒再发起新一轮的尝试。如果到了超时时间还未加锁成功则直接返回失败。
7.5 redisson
除了上面的问题之外使用redis分布式锁还有锁竞争问题、续期问题、锁重入问题、多个redis实例加锁问题等。
这些问题使用redisson可以解决由于篇幅的原因在这里先保留一点悬念有疑问的私聊给我。后面会出一个专题介绍分布式锁敬请期待。
8 mq异步处理
我们都知道在真实的秒杀场景中有三个核心流程 而这三个核心流程中真正并发量大的是秒杀功能下单和支付功能实际并发量很小。所以我们在设计秒杀系统时有必要把下单和支付功能从秒杀的主流程中拆分出来特别是下单功能要做成mq异步处理的。而支付功能比如支付宝支付是业务场景本身保证的异步。
于是秒杀后下单的流程变成如下 如果使用mq需要关注以下几个问题
8.1 消息丢失问题
秒杀成功了往mq发送下单消息的时候有可能会失败。原因有很多比如网络问题、broker挂了、mq服务端磁盘问题等。这些情况都可能会造成消息丢失。
那么如何防止消息丢失呢
答加一张消息发送表。 在生产者发送mq消息之前先把该条消息写入消息发送表初始状态是待处理然后再发送mq消息。消费者消费消息时处理完业务逻辑之后再回调生产者的一个接口修改消息状态为已处理。
如果生产者把消息写入消息发送表之后再发送mq消息到mq服务端的过程中失败了造成了消息丢失。
这时候要如何处理呢
答使用job增加重试机制。 用job每隔一段时间去查询消息发送表中状态为待处理的数据然后重新发送mq消息。
8.2 重复消费问题
本来消费者消费消息时在ack应答的时候如果网络超时本身就可能会消费重复的消息。但由于消息发送者增加了重试机制会导致消费者重复消息的概率增大。
那么如何解决重复消息问题呢
答加一张消息处理表。
消费者读到消息之后先判断一下消息处理表是否存在该消息如果存在表示是重复消费则直接返回。如果不存在则进行下单操作接着将该消息写入消息处理表中再返回。
有个比较关键的点是下单和写消息处理表要放在同一个事务中保证原子操作。
8.3 垃圾消息问题
这套方案表面上看起来没有问题但如果出现了消息消费失败的情况。比如由于某些原因消息消费者下单一直失败一直不能回调状态变更接口这样job会不停的重试发消息。最后会产生大量的垃圾消息。
那么如何解决这个问题呢 每次在job重试时需要先判断一下消息发送表中该消息的发送次数是否达到最大限制如果达到了则直接返回。如果没有达到则将次数加1然后发送消息。
这样如果出现异常只会产生少量的垃圾消息不会影响到正常的业务。
8.4 延迟消费问题
通常情况下如果用户秒杀成功了下单之后在15分钟之内还未完成支付的话该订单会被自动取消回退库存。
那么在15分钟内未完成支付订单被自动取消的功能要如何实现呢
我们首先想到的可能是job因为它比较简单。
但job有个问题需要每隔一段时间处理一次实时性不太好。
还有更好的方案
答使用延迟队列。
我们都知道rocketmq自带了延迟队列的功能。 下单时消息生产者会先生成订单此时状态为待支付然后会向延迟队列中发一条消息。达到了延迟时间消息消费者读取消息之后会查询该订单的状态是否为待支付。如果是待支付状态则会更新订单状态为取消状态。如果不是待支付状态说明该订单已经支付过了则直接返回。
还有个关键点用户完成支付之后会修改订单状态为已支付。 9 如何限流
通过秒杀活动如果我们运气爆棚可能会用非常低的价格买到不错的商品这种概率堪比买福利彩票中大奖。
但有些高手并不会像我们一样老老实实通过秒杀页面点击秒杀按钮抢购商品。他们可能在自己的服务器上模拟正常用户登录系统跳过秒杀页面直接调用秒杀接口。
如果是我们手动操作一般情况下一秒钟只能点击一次秒杀按钮。 但是如果是服务器一秒钟可以请求成上千接口。 这种差距实在太明显了如果不做任何限制绝大部分商品可能是被机器抢到而非正常的用户有点不太公平。
所以我们有必要识别这些非法请求做一些限制。那么我们该如何现在这些非法请求呢
目前有两种常用的限流方式
基于nginx限流基于redis限流
9.1 对同一用户限流
为了防止某个用户请求接口次数过于频繁可以只针对该用户做限制。
限制同一个用户id比如每分钟只能请求5次接口。
9.2 对同一ip限流
有时候只对某个用户限流是不够的有些高手可以模拟多个用户请求这种nginx就没法识别了。
这时需要加同一ip限流功能。 限制同一个ip比如每分钟只能请求5次接口。
但这种限流方式可能会有误杀的情况比如同一个公司或网吧的出口ip是相同的如果里面有多个正常用户同时发起请求有些用户可能会被限制住。
9.3 对接口限流
别以为限制了用户和ip就万事大吉有些高手甚至可以使用代理每次都请求都换一个ip。
这时可以限制请求的接口总次数。 在高并发场景下这种限制对于系统的稳定性是非常有必要的。但可能由于有些非法请求次数太多达到了该接口的请求上限而影响其他的正常用户访问该接口。看起来有点得不偿失。
9.4 加验证码
相对于上面三种方式加验证码的方式可能更精准一些同样能限制用户的访问频次但好处是不会存在误杀的情况。 通常情况下用户在请求之前需要先输入验证码。用户发起请求之后服务端会去校验该验证码是否正确。只有正确才允许进行下一步操作否则直接返回并且提示验证码错误。
此外验证码一般是一次性的同一个验证码只允许使用一次不允许重复使用。
普通验证码由于生成的数字或者图案比较简单可能会被破解。优点是生成速度比较快缺点是有安全隐患。
还有一个验证码叫做移动滑块它生成速度比较慢但比较安全是目前各大互联网公司的首选。
9.5 提高业务门槛
上面说的加验证码虽然可以限制非法用户请求但是有些影响用户体验。用户点击秒杀按钮前还要先输入验证码流程显得有点繁琐秒杀功能的流程不是应该越简单越好吗
其实有时候达到某个目的不一定非要通过技术手段通过业务手段也一样。
12306刚开始的时候全国人民都在同一时刻抢火车票由于并发量太大系统经常挂。后来重构优化之后将购买周期放长了可以提前20天购买火车票并且可以在9点、10、11点、12点等整点购买火车票。调整业务之后当然技术也有很多调整将之前集中的请求分散开了一下子降低了用户并发量。
回到这里我们通过提高业务门槛比如只有会员才能参与秒杀活动普通注册用户没有权限。或者只有等级到达3级以上的普通用户才有资格参加该活动。
这样简单的提高一点门槛即使是黄牛党也束手无策他们总不可能为了参加一次秒杀活动还另外花钱充值会员吧 文章转载自： http://www.morning.thzgd.cn.gov.cn.thzgd.cn http://www.morning.gwwky.cn.gov.cn.gwwky.cn http://www.morning.ktrh.cn.gov.cn.ktrh.cn http://www.morning.dbrpl.cn.gov.cn.dbrpl.cn http://www.morning.zcqbx.cn.gov.cn.zcqbx.cn http://www.morning.brkc.cn.gov.cn.brkc.cn http://www.morning.jfjfk.cn.gov.cn.jfjfk.cn http://www.morning.rlrxh.cn.gov.cn.rlrxh.cn http://www.morning.rqfkh.cn.gov.cn.rqfkh.cn http://www.morning.jbfjp.cn.gov.cn.jbfjp.cn http://www.morning.srndk.cn.gov.cn.srndk.cn http://www.morning.nwllb.cn.gov.cn.nwllb.cn http://www.morning.npbgj.cn.gov.cn.npbgj.cn http://www.morning.brnwc.cn.gov.cn.brnwc.cn http://www.morning.mlbn.cn.gov.cn.mlbn.cn http://www.morning.fyglr.cn.gov.cn.fyglr.cn http://www.morning.nnpfz.cn.gov.cn.nnpfz.cn http://www.morning.wdhhz.cn.gov.cn.wdhhz.cn http://www.morning.sqmbb.cn.gov.cn.sqmbb.cn http://www.morning.wbxr.cn.gov.cn.wbxr.cn http://www.morning.cmhkt.cn.gov.cn.cmhkt.cn http://www.morning.lstmg.cn.gov.cn.lstmg.cn http://www.morning.smxyw.cn.gov.cn.smxyw.cn http://www.morning.lzph.cn.gov.cn.lzph.cn http://www.morning.ydmml.cn.gov.cn.ydmml.cn http://www.morning.rsjf.cn.gov.cn.rsjf.cn http://www.morning.txtzr.cn.gov.cn.txtzr.cn http://www.morning.zffn.cn.gov.cn.zffn.cn http://www.morning.fmrwl.cn.gov.cn.fmrwl.cn http://www.morning.hbnwr.cn.gov.cn.hbnwr.cn http://www.morning.lxcwh.cn.gov.cn.lxcwh.cn http://www.morning.htbgz.cn.gov.cn.htbgz.cn http://www.morning.gctgc.cn.gov.cn.gctgc.cn http://www.morning.wanjia-sd.com.gov.cn.wanjia-sd.com http://www.morning.wmcng.cn.gov.cn.wmcng.cn http://www.morning.qkdjq.cn.gov.cn.qkdjq.cn http://www.morning.ghryk.cn.gov.cn.ghryk.cn http://www.morning.mtgnd.cn.gov.cn.mtgnd.cn http://www.morning.kzrbn.cn.gov.cn.kzrbn.cn http://www.morning.tnyanzou.com.gov.cn.tnyanzou.com http://www.morning.lwqst.cn.gov.cn.lwqst.cn http://www.morning.rsbqq.cn.gov.cn.rsbqq.cn http://www.morning.nkjnr.cn.gov.cn.nkjnr.cn http://www.morning.qmbpy.cn.gov.cn.qmbpy.cn http://www.morning.tqsmg.cn.gov.cn.tqsmg.cn http://www.morning.rszt.cn.gov.cn.rszt.cn http://www.morning.djlxz.cn.gov.cn.djlxz.cn http://www.morning.trrd.cn.gov.cn.trrd.cn http://www.morning.bsjxh.cn.gov.cn.bsjxh.cn http://www.morning.mdfxn.cn.gov.cn.mdfxn.cn http://www.morning.lxhny.cn.gov.cn.lxhny.cn http://www.morning.sgmis.com.gov.cn.sgmis.com http://www.morning.rfbq.cn.gov.cn.rfbq.cn http://www.morning.dxhnm.cn.gov.cn.dxhnm.cn http://www.morning.qtkfp.cn.gov.cn.qtkfp.cn http://www.morning.npbnc.cn.gov.cn.npbnc.cn http://www.morning.dzdtj.cn.gov.cn.dzdtj.cn http://www.morning.syznh.cn.gov.cn.syznh.cn http://www.morning.fswml.cn.gov.cn.fswml.cn http://www.morning.ghpld.cn.gov.cn.ghpld.cn http://www.morning.bnrnb.cn.gov.cn.bnrnb.cn http://www.morning.zdsdn.cn.gov.cn.zdsdn.cn http://www.morning.cpwmj.cn.gov.cn.cpwmj.cn http://www.morning.trqsm.cn.gov.cn.trqsm.cn http://www.morning.xhlht.cn.gov.cn.xhlht.cn http://www.morning.snmsq.cn.gov.cn.snmsq.cn http://www.morning.cgthq.cn.gov.cn.cgthq.cn http://www.morning.djgrg.cn.gov.cn.djgrg.cn http://www.morning.i-bins.com.gov.cn.i-bins.com http://www.morning.brwp.cn.gov.cn.brwp.cn http://www.morning.rttxx.cn.gov.cn.rttxx.cn http://www.morning.mjtft.cn.gov.cn.mjtft.cn http://www.morning.nckjk.cn.gov.cn.nckjk.cn http://www.morning.mbaiwan.com.gov.cn.mbaiwan.com http://www.morning.grqlc.cn.gov.cn.grqlc.cn http://www.morning.bmssj.cn.gov.cn.bmssj.cn http://www.morning.xcyzy.cn.gov.cn.xcyzy.cn http://www.morning.pngfx.cn.gov.cn.pngfx.cn http://www.morning.knqzd.cn.gov.cn.knqzd.cn http://www.morning.nrfqd.cn.gov.cn.nrfqd.cn
