架构师眼中的高并发架构

在高并发业务中如果涉及到数据库操作，主要压力都是在数据库服务器上面，虽然使用主从分离，但是数据库操作都是在主库上操作，单台数据库服务器连接池允许的最大连接数量是有限的?当连接数量达到最大值的时候，其他需要连接数据操作的请求就需要等待有空闲的连接，这样高并发的时候很多请求就会出现connection time out?的情况?那么像这种高并发业务我们要如何设计开发方案可以降低数据库服务器的压力呢？

• 如：
  • 自动弹窗签到，双11跨0点的时候并发请求签到接口
  • 双11抢红包活动
  • 双11订单入库
  • 等
• 设计考虑：
  • 逆向思维，压力在数据库，那业务接口就不进行数据库操作不就没压力了
  • 数据持久化是否允许延迟？
  • 如何让业务接口不直接操作DB，又可以让数据持久化？
• 方案设计：
  • 像这种涉及数据库操作的高并发的业务，就要考虑使用异步了
  • 客户端发起接口请求，服务端快速响应，客户端展示结果给用户，数据库操作通过异步同步
  • 如何实现异步同步？
  • 使用消息队列，将入库的内容enqueue到消息队列中，业务接口快速响应给用户结果(可以温馨提示高峰期延迟到账)
  • 然后再写个独立程序从消息队列dequeue数据出来进行入库操作，入库成功后刷新用户相关缓存，如果入库失败记录日志，方便反馈查询和重新持久化
  • 这样一来数据库操作就只有一个程序(多线程)来完成，不会给数据带来压力
• 补充：
  • 消息队列除了可以用在高并发业务，其他只要有相同需求的业务也是可以使用，如：短信发送中间件等
  • 高并发下异步持久化数据可能会影响用户的体验，可以通过可配置的方式，或者自动化监控资源消耗来切换时时或者使用异步，这样在正常流量的情况下可以使用时时操作数据库来提高用户体验
  • 异步同时也可以指编程上的异步函数，异步线程，在有的时候可以使用异步操作，把不需要等待结果的操作放到异步中，然后继续后面的操作，节省了等待的这部分操作的时间

（编辑：宣城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!