架构阅读笔记14

参考链接

 

高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中。为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。

一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。

高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。

服务器架构图：

 

查询是优先查询缓存，如果缓存不存在，再进行DB查询，将查询结果缓存起来。例如，用户订单：这里我们只缓存用户第一页的订单信息，一页40条数据，用户一般也只会看第一页的订单数据用户访问订单列表，如果是第一页读缓存，如果不是读DB计算出用户分布的key,redis hash中查找用户订单信息，如果查询到用户订单信息，返回订单信息。如果不存在就进行DB查询第一页的订单数据，然后缓存redis，返回订单信息。

秒杀类业务时候就会使用消息队列的，可以将参与用户的信息添加到消息队列中，然后再写个多线程程序去消耗队列，给队列中的用户发放红包。

一级缓存就是使用站点服务器缓存去存储数据，注意只存储部分请求量大的数据，并且缓存的数据量要控制，不能过分的使用站点服务器的内存而影响了站点应用程序的正常运行，一级缓存需要设置秒单位的过期时间，具体时间根据业务场景设定，目的是当有高并发请求的时候可以让数据的获取命中到一级缓存，而不用连接缓存nosql数据服务器，减少nosql数据服务器的压力。数据不会频繁的更新，像这种接口的请求量比较大就可以加入一级缓存。

静态化数据：高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。对于更新频繁度不高，并且数据允许短时间内的延迟，可以通过数据静态化成JSON，XML,HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取，如果没有获取到数据再从缓存，数据库中获取，当管理人员操作后台编辑数据再重新生成静态文件上传同步到CDN，这样在高并发的时候可以使数据的获取命中在CDN服务器上。由于同步有延迟性，需找一个靠谱的服务器商。

其他方案，对于更新频繁度不高的数据，可以缓存数据到本地，然后每次请求接口的时候上传当前缓存数据的版本号，服务端接收到版本号判断版本号与最新数据版本号是否一致，如果不一样就进行最新数据的查询并返回最新数据和最新版本号，如果一样就返回状态码告知数据已经是最新。