消息顺序性为何这么难?
很多业务都需要考虑消息投递的顺序性: 单聊消息投递,保证发送方发送顺序与接收方展现顺序一致 群聊消息投递,保证所有接收方展现顺序一致 充值支付消息,保证同一个用户发起的请求在服务端执行序列一致 消息顺序性是分布式系统架构设计中非常难的问题,有什么常见优化实践呢? 折衷一:以客户端或者服务端的时序为准 不管什么情况,都需要一个标尺来衡量时序的先后顺序,可以根据业务场景,以客户端或者服务端的时间为准,例如: 邮件展示顺序,其实是以客户端发送时间为准的 画外音:发送方只要将邮件协议里的时间调整为1970年或者2970年,就可以在接收方收到邮件后一直“置顶”或者“置底”。 秒杀活动时间判断,肯定得以服务器的时间为准,不可能让客户端修改本地时间,就能够提前秒杀 折衷二:服务端生成单调递增id作为时序依据 对于严格时序的业务场景,可以利用单点写db的seq/auto_inc_id生成单调递增的id,来保证顺序性。 画外音:这个生成id的单点容易成为瓶颈。 折衷三:假如业务能接受误差不大的趋势递增id 消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求: 同1s内发布的聊天消息时序乱了,没...
