支付宝架构师眼中的高并发架构——2

集群

对于用户访问集中的业务独立部署服务器，应用服务器，数据库，nosql数据库。 核心业务基本上需要搭建集群，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务， 服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可, 另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性

 

l  应用服务器集群

n nginx 反向代理

n slb

n … …

l  (关系/nosql)数据库集群

n  主从分离，从库集群

异步

在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的

当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现connection time out 的情况

那么像这种高并发业务我们要如何设计开发方案可以降低数据库服务器的压力呢？

n  如：

n  自动弹窗签到，双11跨0点的时候并发请求签到接口

n  双11抢红包活动

n  双11订单入库

n  等

n  设计考虑：

n  逆向思维，压力在数据库，那业务接口就不进行数据库操作不就没压力了

n  数据持久化是否允许延迟？

n  如何让业务接口不直接操作DB，又可以让数据持久化？

n  方案设计：

n 像这种涉及数据库操作的高并发的业务，就要考虑使用异步了

n 客户端发起接口请求，服务端快速响应，客户端展示结果给用户，数据库操作通过异步同步

n 如何实现异步同步？

n 使用消息队列，将入库的内容enqueue到消息队列中，业务接口快速响应给用户结果(可以温馨提示高峰期延迟到账)

n 然后再写个独立程序从消息队列dequeue数据出来进行入库操作，入库成功后刷新用户相关缓存，如果入库失败记录日志，方便反馈查询和重新持久化

n 这样一来数据库操作就只有一个程序(多线程)来完成，不会给数据带来压力

n  补充：

n  消息队列除了可以用在高并发业务，其他只要有相同需求的业务也是可以使用，如：短信发送中间件等

n  高并发下异步持久化数据可能会影响用户的体验，可以通过可配置的方式，或者自动化监控资源消耗来切换时时或者使用异步，这样在正常流量的情况下可以使用时时操作数据库来提高用户体验

n  异步同时也可以指编程上的异步函数，异步线程，在有的时候可以使用异步操作，把不需要等待结果的操作放到异步中，然后继续后面的操作，节省了等待的这部分操作的时间

缓存

高并发业务接口多数都是进行业务数据的查询，如：商品列表，商品信息，用户信息，红包信息等，这些数据都是不会经常变化，并且持久化在数据库中

高并发的情况下直接连接从库做查询操作，多台从库服务器也抗不住这么大量的连接请求数（前面说过，单台数据库服务器允许的最大连接数量是有限的）

那么我们在这种高并发的业务接口要如何设计呢？

n  设计考虑：

n  还是逆向思维，压力在数据库，那么我们就不进行数据库查询

n  数据不经常变化，我们为啥要一直查询DB？

n  数据不变化客户端为啥要向服务器请求返回一样的数据？

n  方案设计：

n  数据不经常变化，我们可以把数据进行缓存，缓存的方式有很多种，一般的：应用服务器直接Cache内存，主流的：存储在memcache、redis内存数据库

n  Cache是直接存储在应用服务器中，读取速度快，内存数据库服务器允许连接数可以支撑到很大，而且数据存储在内存，读取速度快，再加上主从集群，可以支撑很大的并发查询

n  根据业务情景，使用配合客户端本地存，如果我们数据内容不经常变化，为啥要一直请求服务器获取相同数据，可以通过匹配数据版本号，如果版本号不一样接口重新查询缓存返回数据和版本号，如果一样则不查询数据直接响应

n  这样不仅可以提高接口响应速度，也可以节约服务器带宽，虽然有些服务器带宽是按流量计费，但是也不是绝对无限的，在高并发的时候服务器带宽也可能导致请求响应慢的问题

n  补充：

n  缓存同时也指静态资源客户端缓存

n  cdn缓存，静态资源通过上传cdn，cdn节点缓存我们的静态资源，减少服务器压力

 转自：https://mp.weixin.qq.com/s/g0hUrgVZZ8iv3cDCxDZxpw