消息顺序性为何这么难?
很多业务都需要考虑消息投递的顺序性:
单聊消息投递,保证发送方发送顺序与接收方展现顺序一致
群聊消息投递,保证所有接收方展现顺序一致
充值支付消息,保证同一个用户发起的请求在服务端执行序列一致
消息顺序性是分布式系统架构设计中非常难的问题,有什么常见优化实践呢?
折衷一:以客户端或者服务端的时序为准
不管什么情况,都需要一个标尺来衡量时序的先后顺序,可以根据业务场景,以客户端或者服务端的时间为准,例如:
邮件展示顺序,其实是以客户端发送时间为准的
画外音:发送方只要将邮件协议里的时间调整为1970年或者2970年,就可以在接收方收到邮件后一直“置顶”或者“置底”。
秒杀活动时间判断,肯定得以服务器的时间为准,不可能让客户端修改本地时间,就能够提前秒杀
折衷二:服务端生成单调递增id作为时序依据
对于严格时序的业务场景,可以利用单点写db的seq/auto_inc_id生成单调递增的id,来保证顺序性。
画外音:这个生成id的单点容易成为瓶颈。
折衷三:假如业务能接受误差不大的趋势递增id
消息发送、帖子发布时间、甚至秒杀时间都没有这么精准时序的要求:
同1s内发布的聊天消息时序乱了,没事
同1s内发布的帖子排序不对,没事
用1s内发起的秒杀,由于服务器多台之间时间有误差,落到A服务器的秒杀成功了,落到B服务器的秒杀还没开始,业务上也是可以接受的(用户感知不到)
所以,大部分业务,长时间趋势递增的时序就能够满足业务需求,非常短时间的时序误差一定程度上能够接受。
于是,可以始终分布式id生成算法来生成id,作为时序依据。
折衷四:利用单点序列化,可以保证多机相同时序
数据为了保证高可用,需要做到进行数据冗余,同一份数据存储在多个地方,怎么保证这些数据的修改消息是一致的呢?
“单点序列化”是可行的:
先在一台机器上序列化操作
再将操作序列分发到所有的机器,以保证多机的操作序列是一致的,最终数据是一致的
典型场景一:数据库主从同步
数据库的主从架构,上游分别发起了op1,op2,op3三个操作,主库master来序列化所有的SQL写操作op3,op1,op2,然后把相同的序列发送给从库slave执行,以保证所有数据库数据的一致性,就是利用“单点序列化”这个思路。
典型场景二:GFS中文件的一致性
GFS(Google File System)为了保证文件的可用性,一份文件要存储多份,在多个上游对同一个文件进行写操作时,也是由一个主chunk-server先序列化写操作,再将序列化后的操作发送给其他chunk-server,来保证冗余文件的数据一致性的。
单对单聊天,怎么保证发送顺序与接收顺序一致呢?
单人聊天的需求,发送方A依次发出了msg1,msg2,msg3三个消息给接收方B,这三条消息能否保证显示时序的一致性(发送与显示的顺序一致)?
方案设计思路如下:
(1)如果利用服务器单点序列化时序,可能出现服务端收到消息的时序为msg3,msg1,msg2,就会与发出序列不一致。
(2)业务上不需要全局消息一致,只需要对于同一个发送方A,ta发给B的消息时序一致,常见优化方案,在A往B发出的消息中,加上发送方A本地的一个绝对时序,来表示接收方B的展现时序。
msg1{sender:A, seq:10, receiver:B, msg:content1}
msg2{sender:A, seq:20, receiver:B, msg:content2}
msg3{sender:A, seq:30, receiver:B, msg:content3}
可能存在问题是:如果接收方B先收到msg3,msg3会先展现,后收到msg1和msg2后,会展现在msg3的前面。
群聊消息,怎么保证各接收方收到顺序一致?
群聊消息的需求,N个群友在一个群里聊,怎么保证所有群友收到的消息显示时序一致?
方案设计思路如下:
(1)假设和单聊消息一样,利用发送方的seq来保证时序,因为发送方不单点,seq无法统一生成,可能存在不一致。
(2)于是,可以利用服务器的单点做序列化。
如上图,此时群聊的发送流程为:
(1)sender1发出msg1,sender2发出msg2;
(2)msg1和msg2经过接入集群,服务集群;
(3)service层到底层拿一个唯一seq,来确定接收方展示时序;
(4)service拿到msg2的seq是20,msg1的seq是30;
(5)通过投递服务讲消息给多个群友,群友即使接收到msg1和msg2的时间不同,但可以统一按照seq来展现;
这个方法能实现,所有群友的消息展示时序相同。
缺点是,生成全局递增序列号的服务很容易成为系统瓶颈。
还有没有进一步的优化方法呢?
群消息其实也不用保证全局消息序列有序,而只要保证一个群内的消息有序即可,这样的话,“id串行化”就成了一个很好的思路。
这个方案中,service层不再需要去一个统一的后端拿全局seq,而是在service连接池层面做细小的改造,保证一个群的消息落在同一个service上,这个service就可以用本地seq来序列化同一个群的所有消息,保证所有群友看到消息的时序是相同的。
此时利用本地时钟来生成seq就凑效了,是不是很巧妙?
总结
(1)要“有序”,先得有衡量“有序”的标尺,可以是客户端标尺,可以是服务端标尺;
(2)大部分业务能够接受大范围趋势有序,小范围误差;绝对有序的业务,可以借助服务器绝对时序的能力;
(3)单点序列化,是一种常见的保证多机时序统一的方法,典型场景有db主从一致,gfs多文件一致;
(4)单对单聊天,只需保证发出的时序与接收的时序一致,可以利用客户端seq;
(5)群聊,只需保证所有接收方消息时序一致,需要利用服务端seq,方法有两种,一种单点绝对时序,另一种id串行化;
原文发布时间为:2019-1-3
本文作者: 58沈剑
本文来自云栖社区合作伙伴“ 架构师之路”,了解相关信息可以关注“road5858”微信公众号
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
《RocketMQ技术内幕:RocketMQ架构设计与实现原理》一导读
内容介绍 本书由RocketMQ社区早期的布道者和技术专家撰写,Apache RocketMQ创始人/Linux OpenMessaging创始人兼主席/Alibaba Messaging开源技术负责人冯嘉对其高度评价并作序推荐。 源码角度:本书对RocketMQ的核心技术架构,以及消息发送、消息存储、消息消费、消息过滤、顺序消息、主从同步(HA)、事务消息等主要功能模块的实现原理进行了深入分析,同时展示了源码阅读的相关技巧;应用层面:本书总结了大量RocketMQ的使用技巧。通过阅读本书,读者将深入理解消息中间件和底层网络通信机制的核心知识点。 全书共10章,分三个部分: 第一部分 准备篇(第1章) 首先介绍了RocketMQ源代码的获取、结构和调试,然后介绍了RocketM
- 下一篇
2019金融科技风往哪儿吹?蚂蚁金服联合20余家金融机构预测新年热点:5G、区块链上榜
2019年,金融科技的风向标在哪里?哪些板块成新宠,哪些科技成潮流? 1月4日,蚂蚁金服ATEC城市峰会在上海举行。大会上,蚂蚁金服与20余家金融机构一起预测了2019年金融科技的发展。 “未来金融会像自来水一样触手可及,无时无刻, 只要你打开水龙头,活水自然来。”蚂蚁金服董事长兼CEO井贤栋指出:技术和金融加速融合,正在经历一个从无到有、又从有到无的发展过程,后面这个“无”是无处不在的无。 科技与金融的深度融合促进新型业务形态的产生,开放银行成为2019备受银行业关注的创新方向。华夏银行信息技术部总经理吴永飞认为,开放银行加速客户到用户、封闭到开放、单打独斗到平台经济的转变;随着5G和万物互联时代的到来,开放银行发展会更加迅猛。 人工智能、大数据依旧是2019金融科技创新的关键领域。中国光大集团科技创新事业部总经理、光大科技有限公司总
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果