IM即时通讯构成开发的基础知识(3):快速理解服务器端数据库读写分离的原理和实用建议

 IM即时通讯构成开发的基础知识(3):快速理解服务器端数据库读写分离的原理和实用建议

 1.前言

 从服务器端数据的角度来看，即时消息应用是一个非常特殊的应用场景。除了基础数据、增值服务和辅助功能之外，就聊天数据而言，聊天数据是即时聊天工具的基础，理论上，它不需要存储在服务器端(或者只需要存储很短的时间——例如，离线信息在上线时会被拿走)，这就是为什么微信声称前一段时间不会存储用户聊天数据(技术上，这并不是不合理的)

 那么为什么即时消息系统的服务器在技术上不需要存储聊天数据呢？

 原因很简单。我们知道有两种即时消息聊天数据:

 一个是实时消息(即当你在线而另一方在线时的聊天数据交互)；

 一种是离线消息(即当你在线而另一方不在线时，你发送过去的消息，即离线消息给另一方)。

 发送和接收实时消息:服务器仅充当中转角色(至于中转的技术问题，许多人可能仍在试图解决为什么不使用P2P的旧思想。我已经在论坛上说过，它是腐烂的。坦率地说，这与技术无关。事实上，一个非常重要的原因是操作的可控性:例如，如果用户使用P2P，你能收回非法的大麻吗？)，此时的聊天信息相当于左手对右手——也就是说，聊天数据的本质是它将通过服务器从用户A到用户B完成，并且服务器没有必要存储它(当然，我们讨论的是技术理想的情况，事实上，尽管有技术因素，你是这么多丰富的用户行为数据的操作者，你会放手吗？但这与技术无关，不是吗？

 发送和接收离线消息:当接收者不在线时，发送者的聊天数据只需要作为短因果关系存储在服务器上，因为接收者一旦在线就被拿走，服务器可以删除它(注意:技术上是这样的)。对用户来说，聊天信息的社会学本质就像两个人在聊天。我希望我听到了你说的话。为什么你总是像重复者一样一遍又一遍地告诉我？

 如上所述，即时消息系统中最重要的聊天数据在技术上不需要存储。话虽如此，大型即时消息系统的各个方面的数据量也相当大。因此，在开发即时通讯系统时，有必要讨论服务器端数据库读写分离和横向表分类。因此，您不应该错过本文来快速理解服务器端数据库读写分离的原理。同时，本文还建议您在正确理解的前提下，仔细决定您的服务器端架构方案是否需要对数据库进行读写分离，因为在很多情况下，可以通过添加缓存策略来解决的问题将被消除。

 嗯，几句话后，我们开始读正文。

 2.相关文章

 ▼有几篇关于即时消息数据存储架构的文章，可能对您有用:

 腾讯原创分享(一):如何在移动网络下大幅提高手机QQ的图片传输速度和成功率

 微信大用户后台系统存储架构(视频+PPT)[附件下载]

 微信后台基于时序的海量数据冷热分层架构设计实践

 现代即时通讯系统中聊天信息同步存储方案的探讨

 ▼即时通讯开发干货系列文章适合作为即时通讯开发热点问题的参考材料(本文是其第十二篇文章):

 即时消息传递保证机制的实现(一):保证在线实时消息的可靠传递

 即时消息传递保证机制的实现(二):保证离线消息的可靠传递

 如何确保即时消息的“时间”和“一致性”？》

 我应该使用“推”还是“拉”来同步即时消息单聊和群聊的在线状态？》

 即时消息群聊新闻如此复杂，如何确保它不丢失或沉重？》

 安卓即时通讯智能心跳算法的设计与实现探讨(含示例代码)

 “当即时消息登录移动终端时，如何通过提取数据来节省流量？》

 易于理解:基于集群共享移动终端即时通信接入层的负载均衡方案

 浅谈移动即时通信的多点登录和消息漫游原理

 构成即时通讯开发的基础知识(一):正确理解前端HTTP单点登录接口的原理

 构成即时消息开发的基础知识(2):如何为大量图像文件设计服务器端存储架构？》

 补充即时通讯开发的基础知识(3):快速了解服务器端数据库读写分离的原理和实用建议(本文)

 构成即时消息开发的基础知识(4):正确理解短连接中的Cookie、会话和令牌

 如何实现即时通讯群聊信息的阅读回执功能？》

 即时消息群聊消息是一份拷贝(即扩散阅读)还是多份拷贝(即扩散写作)？》

 构成即时消息开发的基础知识(5):易于理解、正确理解并充分利用MQ消息队列

 一种低成本保证即时消息定时的方法探讨

 补上一课关于即时消息开发的基础知识(6):您的数据库使用NoSQL还是SQL？读读这个！》

 在即时通讯中实现“身边人”功能的原则是什么？如何有效地实现它？》

 构成即时通讯开发的基础知识(七):主流移动账户登录方法的原理和设计思路

 弥补即时通讯发展的基础知识(8):历史上最流行的，彻底了解字符乱码问题的本质

 如何实现即时通讯的扫描码板功能？有一篇文章了解主流应用的扫描代码登陆技术的原理

 “即时通讯做手机扫描码登录？让我们先来看看微信扫描码登录功能的技术原理

 如果你是即时通讯开发的初学者，强烈建议你先阅读“初学者:从头开始开发移动即时通讯”。

 3.什么是数据库读写的分离？

 补充即时通讯开发的基础知识(3):快速理解服务器端数据库读写分离的原理和实用建议_1.png

 如上图所示，一个主机和多个从机、读写分离和主动同步是常见的数据库体系结构。

 一般来说:

 主图书馆-提供数据库写作服务；

 从图书馆-提供数据库阅读服务。

 主库和从库通过某种机制同步数据，比如mysql的binlog。

 如上图所示，主从同步集群通常被称为“数据包”。

 那么，数据库“分组”架构解决了什么问题？

 大多数互联网服务读得多写得少，而数据库读取往往成为第一个性能瓶颈。如果您愿意:

 线性提高数据库的读取性能；

 通过消除读写锁冲突提高数据库写入性能；

 此时，您可以使用分组架构。

 总而言之，“分组”主要解决“数据库读取性能瓶颈”的问题。当数据库不支持读取时，采用“分组”结构实现读写分离，通过增加从机数量线性提高系统的读取性能。

 4.什么是水平数据库分段？

 补充即时通讯开发的基础知识(3):快速理解服务器端数据库读写分离的原理和实用建议_2.png

 如上图所示，正如数据库“分组”体系结构实现了读写分离一样，水平分区(也称为大表拆分和表拆分)也是一种常见的数据库体系结构手段。

 一般来说:

 每个数据库之间没有数据重叠，也没有类似于binlog同步的关联；

 所有数据被组合以形成所有数据；

 将使用算法来完成数据分割，如“模”；

 集群中每个数据库的水平分区通常称为“切片”。

 水平分割架构到底解决了什么问题？

 大多数互联网服务都有大量的数据，单个数据库的容量很容易成为瓶颈。如果您愿意:

 单个数据库数据容量的线性缩减；

 数据库写入性能的线性改进；

 此时，可以使用水平切片架构。

 总而言之:数据库水平分区体系结构主要解决“大量数据库数据”(或者更具体地说，单个表中的数据量太大)的问题，当数据库容量不堪重负时，通常是水平分区的。

 5.虽然数据库读写的分离是好的，但是不应该被滥用

 对于具有大量数据、高并发性、高可用性、高一致性和面向用户的前端的业务场景，如果数据库是单独读写的:

 需要区分数据库连接池:读连接池和写连接池；

 如果要保证高读的可用性，读连接池应该实现自动故障转移；

 主库和从库之间存在潜在的一致性问题。

 补充即时通讯开发的基础知识(3):快速理解服务器端数据库读写分离的原理和实用建议_3.png

 事实上，如果您的系统面临“读取性能瓶颈”的问题，增加缓存可能会更直接、更容易。

 此外，在成本方面，从库的成本远远高于缓存的成本。此外，对于云架构，以阿里巴巴云为例，主库提供高可用性服务，而从库不提供高可用性服务，因此实施方案更为主流。

 因此，在上述业务场景下，建议使用缓存架构来提高系统读取性能，取代数据库的主从分离架构。

 当然，使用缓存体系结构的潜在问题是，如果缓存被挂起，数据库上的流量将全部被压缩，数据库将会崩溃。幸运的是，云中的缓存通常提供高度可用的服务。

 6.简单总结

 在典型的大规模互联应用架构中，服务器端数据库架构主要使用以下两种类型:

 利用“分组”架构实现数据库读写分离:解决“数据库读取性能瓶颈”问题；

 用“切片”结构实现数据库的水平分割:解决“数据库数据量大”的问题。

 然而，对于具有大量数据、高并发性、高可用性、高一致性和面向用户的前端的业务场景，在许多情况下，微服务缓存体系结构可能比数据库读写分离体系结构更合适。