IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

  • 时间:
  • 浏览:1
  • 来源:5分排列5_5分排列3

水平切分架构究竟出理 哪些问題?

>> 更多例如文章 ……

《微信技术总监谈架构:微信之道——大道至简(演讲全文)》

得话总结:数据库水平切分架构主要出理 “数据库数据量大”(不可能 更细随后 说是单表数据量这样来越多)问題,在数据库容量扛不住的时候,通常水平切分。

但对于互联网大数据量、高并发量、高可用要求高、一致性要求高、前端面向用户的业务场景,使用微服务缓存架构,随后 随后 时候不可能 比数据库读写分离架构更要花费。

《即时通讯安全篇(三):常用加解密算法与通讯安全讲解》

如上图所示,跟数据库“分组”架构实现读写分离一样,水平切分(也称大表拆分、分表),也是两种常见的数据库架构手段。

不可能 您是IM开发初学者,强烈建议首先阅读《新手入门一篇就够:从零开发移动端IM》。

得话总结:“分组”主要出理 “数据库读性能瓶颈”问題,在数据库扛不住读的时候,用“分组”架构实现读写分离,通过增加从库线性提升系统读性能。

《腾讯原创分享(一):何如大幅提升移动网络下手机QQ的图片传输下行时延 和成功率》

《微信后台基于时间序的海量数据冷热分级采集实践》

《微信海量用户身后的后台系统存储架构(视频+PPT) [附件下载]》

《IM开发基础知识补课(一):正确理解前置HTTP SSO单点登陆接口的原理》

[2] 有关IM安全的文章:

《浅谈移动端IM的多点登陆和消息漫游原理》

《浅谈IM系统的采集》

2)从库——提供数据库读服务。

《IM单聊和群聊中的在线情况表同步应该用“推”还是“拉”?》

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》

《移动端IM中大规模群消息的推送何何如证下行时延 、实时性?》

1)线性降低单库数据容量;

(本文同步发布于:http://www.52im.net/thread-1366-1-1.html)

《IM单聊和群聊中的在线情况表同步应该用“推”还是“拉”?》

3)此时还都还可以使用分组架构。

随后 随后 ,上述业务场景下,建议使用缓存架构来加强系统读性能,替代数据库主从分离架构。

▼ 跟IM数据存储架构有关的文章,有如下几篇,或许对你有用:

《微信后台基于时间序的海量数据冷热分级采集实践》

1)主库——提供数据库写服务;

《即时通讯安全篇(四):实例分析Android中密钥硬编码的风险》

这样,数据库“分组”架构究竟出理 哪些问題?

[3] IM开发综合文章:

如上图所示,一主多从、读写分离、主动同步,是两种常见的数据库架构。

本文正文要素引用了58同城架师沈剑的文章,非常感谢他的分享。

当然,使用缓存架构的潜在问題:不可能 缓存挂了,流量详细压到数据库上,数据库会雪崩。不过幸好,云上的缓存一般都提供高可用的服务。

《腾讯原创分享(一):何如大幅提升移动网络下手机QQ的图片传输下行时延 和成功率》

这样为哪些说IM系统的服务端从技术上说,是不还要存储聊天数据的呢?

《即时通讯系统的原理、技术和应用(技术论文)》

《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》

《QQ音乐团队分享:Android中的图片压缩技术详解(下篇)》

《理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)》

《来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享》

《即时通讯安全篇(二):探讨组合加密算法在IM中的应用》

原因分析分析很简单,让另一个人知道IM的聊天数据分两种:

对于互联网大数据量、高并发量、高可用要求高、一致性要求高、前端面向用户的业务场景,不可能 数据库读写分离:

《IM开发基础知识补课(二):何如设计大量图片文件的服务端存储架构?》

2)使用“分片”架构实现数据库水平切分:出理 “数据库数据量大”问題。

《详细自已开发的IM该何如设计“失败重试”机制?》

2)所有数据并集,组成详细数据;

离线消息的收发:当接收方不出线时,发送方的聊天数据在服务端只还要作短因果报应存储,不可能 接收方一旦上线就拉走了,服务器删除即可(注意:从技术上来说却说曾经的哦)。对用户而言聊天消息的社会学的本质来说就像曾经人在对话,我不可能 听见我知道你的就好了,干吗老像复读机一样一遍一遍一说给我听?

大要素互联网业务读多写少,数据库的读往往最先成为性能瓶颈,不可能 希望:

2)通过消除读写锁冲突提升数据库写性能;

《腾讯原创分享(二):何如大幅压缩移动网络下APP的流量消耗(下篇)》

>> 更多例如文章 ……

一般来说:

2)不可能 要保证读高可用,读连接池要实现故障自动转移;

大要素互联网业务数据量很大,单库容量容易成为瓶颈,不可能 希望:

《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》

《简述实时音视频聊天中端到端加密(E2EE)的工作原理》

《请问另一个人知道语音留言聊天的主流实现措施吗?》

《两种Android端IM智能心跳算法的设计与实现探讨(含样例代码)》

[1] 有关IM采集:

《即时通讯安全篇(一):正确地理解和使用Android端加密算法》

《如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源》

实际上,不可能 您的系统面临的是“读性能瓶颈”问題,增加缓存不可能 来得更直接,更容易随后 。

《何何如证IM实时消息的“时序性”与“一致性”?》

2)两种是离线消息(都不 你在线,对方不出线时,你发过去的消息,对于对方而言却说离线消息了)。

正如上述所言,IM系统中最重要的聊天数据从技术上不说我我觉得是这样存储的必要的。不过话虽这样,但曾经大型的IM系统的方方面面数据量也是很可观的,随后 随后 开发IM系统时讨论服务端数据库的读写分离、水平分表等,是很有必要的。因而通过本文快速理解服务端数据库的读写分离原理你不应错过,本文也共同建议您在正确理解它的前提下再慎重决定您的服务端架构方案不是还要数据库读写分离,不可能 随后 随后 时候增加缓存策略就能出理 的问題,就这样必在大炮打蚊子了。

《Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)》

《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》

《通俗易懂:一篇掌握即时通讯的消息传输安全原理》

3)会用算法,来完成数据分割,例如“取模”;

实时消息的收发:服务端只作为中转角色(关于中转的技术问題,随后 随后 人不可能 还在结纠老思维为什么我么我么不会P2P,我不可能 论坛说烂了,说白了跟技术无关,我我觉得曾经不得劲要的原因分析分析却说为了运营的可控性:比如用户P2P去了,违法的锅你运营方来背好不好?),聊天消息在此时就要花费左手倒右手——即聊天数据的本质却说从A用户经过服务端到达B用户就完了,服务端详细没必要存储(当然,让另一个人讨论的是技术理想情况表,实际上抛开技术因素来说,这样多富足的用户行为数据你是运营方随后 你放过吗?但,这跟技术无关对吧)。

《QQ音乐团队分享:Android中的图片压缩技术详解(上篇)》

>> 更多例如文章 ……

《基于社交网络的Yelp是何如实现海量用户图片的无损压缩的?》

一般来说:

IM应用从服务端数据的时延来看,它是两种很特殊的应用场景,抛开基础数据、增值业务和附属功能不谈,单从IM聊天工具的立身之本——聊天数据来说,理论上是不还要在服务端存储的(不可能 说只还要短暂存储——比如离线消息,上线即拉走),这也是为哪些微信在前段时间号称绝不存储用户聊天数据的原因分析分析(从技术上说这都不 这样道理的,但到底有这样存储,这不可能 超越技术范畴了,不出此文讨论之列 ^_^)。

《谈谈移动端 IM 开发中登录请求的优化》

(本文同步发布于:http://www.52im.net/thread-1366-1-1.html)

《微信新一代通信安全出理 方案:基于TLS1.3的MMTLS详解》

2)线性提升数据库写性能;

《开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀》

3)此时还都还可以使用水平切分架构。

▼ IM开发干货系列文章适商务商务合作为IM开发热点问題参考资料(本文是其第12篇):

1)使用“分组”架构实现数据库读写分离:出理 “数据库读性能瓶颈”问題;

《浅谈移动端IM的多点登陆和消息漫游原理》

《开发IM是自己设计协议用字节流好还是字符流好?》

《通俗易懂:基于集群的移动端IM接入层负载均衡方案分享》

《移动端安全通信的利器——端到端加密(E2EE)技术详解》

《现代IM系统中聊天消息的同步和存储方案探讨》

《IM消息送达保证机制实现(二):保证离线消息的可靠投递》

1)线性提升数据库读性能;

《IM群聊消息这样多样化,何何如证不丢不重?》

《IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议》(本文)

《何如解读《微信技术总监谈架构:微信之道——大道至简》》

《简述移动端IM开发的哪些坑:采集、通信协议和客户端》

《腾讯原创分享(二):何如大幅压缩移动网络下APP的流量消耗(上篇)》

《从零到卓越:京东客服即时通讯系统的技术架构演进历程》

《移动端IM开发还要面对的技术问題》

《移动端IM登录时拉取数据何如作到省流量?》

《IM消息送达保证机制实现(二):保证离线消息的可靠投递》

《微信对网络影响的技术试验及分析(论文全文)》

《通俗易懂:基于集群的移动端IM接入层负载均衡方案分享》

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《移动端IM登录时拉取数据何如作到省流量?》

《曾经低成本确保IM消息时序的措施探讨》

《IM开发基础知识补课(二):何如设计大量图片文件的服务端存储架构?》

1)两种是实时消息(都不 你在线,对方也在线情况表下的聊天数据交互);

《即时通讯安全篇(五):对称加密技术在Android平台上的应用实践》

《何何如证IM实时消息的“时序性”与“一致性”?》

3)主从库之间,通过两种机制同步数据,例如mysql的binlog。

4)曾经水平切分集群中的每曾经数据库,通常称为曾经“分片”。

《IM群聊消息这样多样化,何何如证不丢不重?》

4)像上述图中曾经,曾经主从同步集群通常被称为曾经“分组”。

《即时通讯安全篇(六):非对称加密技术的原理与应用实践》

- 即时通讯开发交流群:320837163[推荐]

1)数据库连接池还要区分:读连接池,写连接池;

3)有潜在的主库从库一致性问題。

《17年的实践:腾讯海量产品的技术措施论》

1)每个数据库之间这样数据重合,这样例如binlog同步的关联;

《快速裂变:见证微信强大后台架构从0到1的演进历程(一)》

《移动端IM中大规模群消息的推送何何如证下行时延 、实时性?》

《蘑菇街即时通讯/IM服务器开发之架构确定》

典型的大型互联应用架构中,服务端数据库架构主要使用以下两种:

《一套原创分布式即时通讯(IM)系统理论架构方案》

好了,费话多说了几句,让另一个人刚开始阅读正文。

《IM开发基础知识补课:正确理解前置HTTP SSO单点登陆接口的原理》

另外,从成本上说,从库的成本比缓存高不少。却说对于云上的架构,以阿里云为例,主库提供高可用服务,从库不提供高可用服务,实现方案上更主流。

《一套海量在线用户的移动端IM采集实践分享(含详细图文)》

《现代IM系统中聊天消息的同步和存储方案探讨》