数据分片本质上通过提高系统的可扩展性来支撑高并发写请求的.每当写请求量达到一个新高度时.系统就需要数据分片扩容.从产品发展角度来看,这本无可厚非.但是扩容就意味着需要更多昂贵的服务器资源.经济成本较高.况且扩容就意味着需要更多昂贵的服务器资源.经济成本较高.况且扩容不是一个实时操作.对临时的突增流量很难及时应对.
异步写:
异步写是一个泛化的概念.并不局限于实现形式.异步写把请求的交互流程从"用户发起写请求并同步等待结果返回"转变为"用户提交写请求后"的两阶段交互.
1.将用户写请求先以适当的方式快速暂存到一个数据池中.然后立刻响应用户,告知其请求提交成功.以便缩短写请求的响应时间.
2.真正的写操作由后台任务不断的从数据池中读取请求并真正执行.
3.写操作结果依靠用户主动查询.有的业务场景为了提高实时性.也会在写操作执行完成结束后主动将结果通知给用户.
异步写非常适合写请求量大.但是被请求方的系统吞吐量跟不上的场景.写请求先排队.被请求方以正常的速度处理请求.
跨公网调用:
某电商类产品接入微信支付支付宝等渠道来做支付功能.这些渠道都属于第三方平台.即不属于本产品的后台服务.这就意味着需要跨公网调用第三方平台的支付接口.而公网调用的网络耗时和网络抖动很严重.同时大量的用户支付请求到来会导致跨公网调用发生阻塞.由于跨公网调用的速度无法匹配支付请求的速度.所以使用异步方案可以很好的解决.如图所示.使用消息中间件对用户支付请求进行排队操作.并通过消息消费者不断地消费用户支付请求.逐个跨公网调用第三方平台的支付接口.
秒杀系统异步化:
在产品秒杀活动中.对于其他电商产品.在同一时间会有大量的用户抢购请求涌入服务器.如果每个请求都会直接访问数据库进行扣减库存和写入订单操作,那么数据库将会承受巨大的压力.可以通过异步写方案将抢购动作变成异步形式:用户点击"抢购"按钮.秒杀服务将抢购请求提交到消息中间件.而后立即响应用户---"抢购中".消息消费者按照数据库的真实处理能力.低频甚至串行的消费抢购请求并交给数据库处理.数据库处理完成后.将处理结果保存到Redis中.用户可以刷新订单页向Redis查询抢购结果.秒杀系统的异步化架构大致如图.
写聚合:
写聚合将若干写请求聚合为一个写请求.减少了写请求量.
1.Kafka Producer批量生产:
为了提升消息生产者的消息发送性能.消息中间件Kafka提供了Micro-Batch概念.Micro-Bathch提供了一个名为RecordAccumulator的消息收集器.它会将Producer待发送的消息暂存在内存中.并将相同的Topic 相同的Partition的消息聚合为一个批次.然后一次性发送到Kafka集群.大大提高了Kafka发送消息的吞吐量.
2.AliSQL热点数据优化:
由于行锁的存在.在数据库中处理热点数据更新一直是一个难题.对某行热点数据的变更请求会相互竞争同一个行锁.性能一直难以得到提升.阿里云深度定制的MySQL分支AliSQL对热点数据的更新有专门优化.将对同一行的多个更新操作聚合为一个批次的更新操作.消除了行锁竞争.提高了热点数据的更新效率.