IM 去中心化概念模型与架构设计
今天打算写写关于 IM 去中心化涉及的架构模型变化和设计思路,去中心化的概念就是说用户的访问不是集中在一个数据中心,这里的去中心是针对数据中心而言的。
站在这个角度而言,实际上并非所有的业务都能做去中心化设计,对于一致性要求越高的业务去中心化越难做。比如电商领域的库存就是一个对一致性要求很高的业务,不能超卖也不能少卖,这在单中心容易实现,但多中心纯从技术层面感觉无解,可能需要从业务和技术层面一起去做个折衷。
反过来看 IM 的业务场景是非常适合做去中心化设计的,因为其业务场景都是弱一致性需求。打开你的微信或 QQ 仔细观察下,对大部分人来说与你联系最频繁的实际多是在地域上离你最近的人,人与人之间的心理距离和物理距离会随着时间渐趋保持一致。所以根据这个特点,按地域来分布数据中心和聚合人群是比较合适的。
在进入去中心化 IM 架构模型之前,我们先看看中心化架构是怎样的,分析其关键设计再来看如果要去中心化需要做哪些变化?
中心化
IM 的中心化架构并不意味着只有一个数据中心,它也可以是多数据中心的,如下图。
之所以说它是中心化架构,关键特征是其存在共享的数据存储。部署在两个数据中心的应用需要共享访问统一的数据存储,而这种共享访问实际是依赖数据中心之间的专线连通,这样的架构也限制了能选取的数据中心地理位置的距离。而实现去中心架构的关键点就在于规避跨数据中心的共享存储访问,使得应用在其自身数据中心实现访问闭环。
我们这里只分析下实现 IM 消息互通这个最重要场景下共享数据存储里需要存些什么数据呢?一个是用户上线后的「座标」,主要指用户本次在线接入了哪台机器的哪根连接,这个「座标」用于在线消息投递。而另一方面若用户离线时,别人给它发消息,这些消息也需要存储下来,一般称为用户的「离线消息」,下次用户上线就可以自动收取自己的离线消息。
中心化架构实际能做到的极致就是把读实现自有数据中心闭环,而写依然需要向主数据中心所在的存储写入。而 IM 的写入场景还不算是一个低频操作,那么要实现去中心化架构关键点就在如何解决写的问题上。
去中心化
在设计 IM 的去中心化架构之前,希望去实现这个架构并编写代码时,不需要去考虑最终部署到底是去中心的还是中心的。编码时就像开发中心化架构一样去实现场景的功能,而去中心化的能力做为纯基础的技术能力,通过附加的方式来获得,先看看架构图的变化,如下。
这里的变化是为「座标」增加一个「数据中心」纬度,当按通用的方式去本地存储定位用户时,发现一个非本地的座标时消息该怎么投递?这里可以在每个本地数据中心额外添加一个消息网关程序,注册到本地存储中,并负责接收所有非本地座标的消息,这有点像路由网络中的边界网关。
消息网关统一接收应当发往其他数据中心的消息,以实现跨数据中心的消息流转。这里有个疑问是其他数据中心的「座标」是怎么跑到本地来的?离线消息的场景又该如何处理呢?关于这两个问题,就涉及到我们解决跨数据中心同步数据的关键技术了。
关键技术
结合 IM 的业务场景,实际它对同步的延时具有一定的容忍度。所以我觉得基于 Gossip 协议的小道消息传播特性就能很好的满足这个同步场景。
关于 Gossip 我是在新近的 NoSQL 数据库 Cassandra 上听说的,后来 Redis Cluster 也利用了该协议来实现无中心化集群架构。但 Gossip 协议可不是什么新东西,实际关于它的诞生可以追溯到好几十年前的施乐研究中心,就是为了解决数据库同步问题被我们的前前前辈想出来的。
这个协议的灵感来自于办公室小道消息的传播路径,当一个人知道了一条小道消息,他碰到一个朋友并随口告诉了他,朋友又告诉了朋友的朋友,没多久整个办公室都知道了,也就完成了信息的同步。借用这个模型,实际上我们需要同步的信息就是用户的在线「座标」和「离线消息」。
因为 Gossip 自好几十年前已经有很多论文证明并公开发表,而且近年也有 Cassandra 和 Redis 的成功工程实践,所以我就先不用去怀疑其可行性,而是直接利用其结论了。根据其特性,分析 IM 的去中心场景在引入 Gossip 后有些什么可供观察的变化和值得注意的方面。
在一个稍具规模的 IM 场景下,用户总是在上上下下,消息也在不停的在「在线」和「离线」之间变化,所以需要通过 Gossip 同步的信息是时时存在的。所以假设我们在某个时刻去拍一个快照(实际做不到),得到的结果是多个数据中心的数据肯定是不一致的,几乎不存在所谓的全局最终一致性的某一时刻。在这样的客观环境下,对 IM 的业务场景有多大影响?
当用户A在 IDC#1 在线,用户B 在 IDC#2 刚上线,这里存在一个同步时差,那么此时用户A给用户B发消息,在本地没有用户B的座标,所以进入离线消息池。用户B此时不能立刻收到用户A的消息,但离线消息池会在随后通过 Gossip 协议同步到用户B所在的 IDC#2,用户B此时就可以通过离线消息收取用户A的消息。
上面描述了一种临界场景,在这种临界场景下,用户收消息存在延时。而这种临界场景实际上并不是常态,而且 IM 用户实际对这种刚上线的消息延时存在很高的容忍度。这一点我想大家用 QQ 可能体会过,有时一上线都一分钟了,还会收到之前的离线消息,我不知道这是有意的延时还是真有这么长的系统延时。
那么使用 Gossip 协议从理论上来估算下会产生多久的延时?假设我们在全国东西南北中各部署一个数据中心,一共五个。五个数据中心之间无专线,走公网互通,网络延时最大 200 ms。使用 Gossip 完成在五个数据中心的最终一致性同步最大需要多长时间?这里我直接引用 Gossip 论文结论:
Cycles = log(N) + ln(N) + O(1)
当 N=5 时,完成全部同步,需要节点间私下传播的次数,套用公式得到 3.3 次,取整得 4 次。按最大网络延时 200 ms,每次 Gossip 交换信息间隔 100 ms,那么协议本身固有延时大约 4x200 + 4x100 = 1.2s,而再算上程序开销,这个延时很可能在数秒内波动,这个量级的延时对于少数的临界场景是完全可以接受的。
总结
本文的标题是概念模型,但它不像另外一篇《RPC 的概念模型与实现解析》跟了实现解析,说明这只是一个理论推导。因为里面最关键的是如何配合 Gossip 的共享存储似乎没有找到特别适合的产品,要是自己做一个呢就会产生一种今天只想出去兜兜风,却要先自己动手造辆车的感觉。
参考
[1]. Wikipedia. Gossip protocol. 2016.03.29
[2]. ALVARO VIDELA. GOSSIP PROTOCOLS, WHERE TO START. 2015.12.02
[3]. Anne-Marie et al. Gossiping in Distributed Systems. 2007
[4]. Márk Jelasity. Gossip Protocols
[5]. Alberto Montresor. Gossip protocols for large-scale distributed systems. 2010
写点程序世间的文字,画点生活瞬间的画儿。
微信公众号「瞬息之间」,遇见了不妨就关注看看。
IM 去中心化概念模型与架构设计的更多相关文章
- 为什么比特币和以太坊未必真得比EOS更去中心化?
在区块链行业里,有两派人一直在争论:一个是以比特币和以太坊为首的社群,另一个是以EOS为首的社群.这两群人一直在争论谁才是真正的未来,双方都认为自己这边更有未来.其中EOS抗争的重点就是100万TPS ...
- 一种去中心化的manager设计思路
通常,我们设计游戏引擎时,或者管理器时,都会由管理器产出各种产品,一旦有新产品要加,就要修改管理器,来增加相应的生成代码. 这从设计上来看有两个问题: 1,管理器参数需要有个类型,在管理器中用if e ...
- 去中心化存储项目终极指南 | Filecoin, Storj 和 PPIO 项目技术对比(下)
在上篇文章中,我们主要从价值定位.技术层次架构.服务质量.去中心化程度,和经济激励机制五个方面分析了三个项目的不同.在这一篇文章中,我们将着重从区块链的架构设计.数据传输技术设计和数据存储技术设计三方 ...
- 去中心化存储项目终极指南 | Filecoin, Storj 和 PPIO 项目异同
Filecoin,Storj 以及 PPIO 这三个存储公链的设计思路是不一样的,没有优劣之分,写这篇文章也并不是为了争论各项目的好坏对错.去中心化存储是一个长期商业赛道,不同团队在同一个赛道上往不同 ...
- Filecoin:一种去中心化的存储网络(一)
开始初步了解学习Filecoin,如下是看白皮书的内容整理. 参考: 白皮书中文版 http://chainx.org/paper/index/index/id/13.html 白皮书英文版 http ...
- 小众Tox——大众的“去中心化”聊天软件
★Tox是什么 一个反窥探的开源项目:一种基于DHT(BitTorrent)技术的即时通讯协议:一个为安全而生的加密通讯系统 .美国棱镜计划曝光后,一个名为 irungentoo 的牛人于17天后的2 ...
- 一个轻client,多语言支持,去中心化,自己主动负载,可扩展的实时数据写服务的实现方案讨论
背景 背景是设计一个实时数据接入的模块,负责接收client的实时数据写入(如日志流,点击流),数据支持直接下沉到HBase上(兴许提供HBase上的查询),或先持久化到Kafka里.方便兴许进行一些 ...
- eos中BM与有BM特色的去中心化。区块链世界,白皮书为共识,代码为法律。
比特币挖矿是谁算力高,谁更容易挖到新的比特币,而BM认为这太浪费资源了,于是设计了DPoS:在DPoS系统里,大家不再挖矿.而是指定几个人负责记账,不叫矿工,而叫见证人.比特股里开始是101人,EOS ...
- PPIO去中心化存储的了解和记录
目录 介绍 FileCoin P2P技术给去中心化云存储的好处 剩余资源的再次使用 市场竞争会激发民间的智慧 PPIO的2种冗余模式 全副本模式 纠删副本模式 为什么PPIO要设计支付代理节点? 一些 ...
随机推荐
- NodeJs之OS
OS Node.js提供了一些基本的底层操作系统的模块OS. API var os = require('os'); console.log('[arch] 操作系统CPU架构'+os.arch()) ...
- SQLServer文件收缩-图形化+命令
汇总篇:http://www.cnblogs.com/dunitian/p/4822808.html#tsql 收缩前 图形化演示: 不仅仅可以收缩日记文件,数据库文件也是可以收缩的,只不过日记收缩比 ...
- Flexible 弹性盒子模型之CSS flex-grow 属性
实例 让第二个元素的宽度为其他元素的三倍: div:nth-of-type(1){flex-grow:1;} div:nth-of-type(2){flex-grow:3;} div:nth-of-t ...
- H5 canvas的 width、height 与style中宽高的区别
Canvas 的width height属性 1.当使用width height属性时,显示正常不会被拉伸:如下 <canvas id="mycanvas" width=&q ...
- sqlyog导出json数据格式支持mysql数据转存mongodb
<!-------------知识的力量是无限的(当然肯定还有更简单的方法)-----------!> 当我考虑将省市区三级联动数据从mysql转入mongodb时遇到了网上无直接插入mo ...
- JS案例之2——cycle元素轮播
元素轮播效果是页面中经常会使用的一种效果.这个例子实现了通过元素的隐藏和显示来表现轮播效果.效果比较简单. 效果图如下: 源代码如下: <!DOCTYPE html> <html&g ...
- css样式让input垂直居中
css样式让input垂直居中 css代码: .div1{ border: 1px solid #CCC; width:1120px; height:40px; margin:auto; displa ...
- SQL Server2014 SP2关键特性
SQL Server2014 SP2关键特性 转载自:https://blogs.msdn.microsoft.com/sqlreleaseservices/sql-2014-service-pack ...
- ASP.NET 5 和Entity Framework 7公告仓库
ASP.NET 5 有一个公告仓库来介绍ASP.NET 5和 Entity Framework 7的主要变更说明,这个对于日夜更新的项目来说,很多人经常会遇到问题但是不知道去哪里寻找帮助,很多同学在做 ...
- SSH免密码登录
每次用SSH登录服务器都要输入密码,次数多了就觉得有些麻烦,反正是自己个人用的电脑,安全应该有保障,如何能直接登录上去而不需要输入密码呢?其实一句话就讲清楚了:把自己公钥放在服务器上. Linux客户 ...