![](https://img-blog.csdnimg.cn/20201014180756927.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
即时通讯IM
普通网友
这个作者很懒,什么都没留下…
展开
-
IM 架构设计10
从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路上图模型中消息轮询模块的长连接请求是通过 php-fpm 挂载在阻塞队列上,当该请求变多时,如果不能及时释放 php-fpm 进程,会对服务器性能消耗较大,负载很高。为了解决这个问题,我们对消息轮询模块进行了优化,选用基于 OpenResty 框架,利用 Lua 协程的方式来优化 php-fmp 长时间挂载的问题。Lua 协程会通过对 Nginx 转发的请求标记判断是否拦截网络请求,如果拦截,则会将阻塞操作交给 Lua 协程来处理,及时释放原创 2020-08-11 15:20:49 · 391 阅读 · 0 评论 -
IM 架构设计09
以微博类应用场景为例,总结海量社交系统的架构设计步骤原创 2020-08-09 20:56:56 · 134 阅读 · 0 评论 -
IM 架构设计08
微信朋友圈千亿访问量背后的技术挑战和实践总结但重试由于会造成请求的增加,所以是把双刃剑,节日高峰期间由于请求本身涨幅已经很高,重试更容易引发问题,需要进行调整:1)通过master路由下发,关闭重试。在元旦/春节这种请求有数倍增长的节日实行; 2)值班人员严密监控,如果IDC失败率超过20%,则紧急手工关闭重试。这种在中秋/国庆这种增长并不高的节日实行。业务侧春节要求的增长比例,是上传支持9倍增长,下载支持1倍增长,超过这个比例的请求可以拒绝掉,但根据预算扩容后..原创 2020-08-09 16:29:16 · 181 阅读 · 0 评论 -
IM 架构设计07
IM开发基础知识补课(一):正确理解前置HTTP SSO单点登陆接口的原理IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?在早期的很多基于Linux开源架构的网站中,如果不想同步图片,可能会利用NFS来实现。事实证明,NFS在高并发读写和海量存储方面,效率上存在一定问题,并非最佳的选择,所以大部分互联网公司都不会使用NFS来实现此类应用。当然,也可以通过Windows自带的DFS来实现,缺点是“配置复杂,效率未知,而且缺乏资料大量原创 2020-08-07 23:21:00 · 209 阅读 · 0 评论 -
IM 架构设计06
微信后台基于时间序的海量数据冷热分级架构设计实践1. 数据量大:PB 级数据,万亿级键值,并且在源源不断的生成中,然而新生成的数据相较于历史存量数据占比小。下图展示了该集群数据在各时间段的一个占比情况2. 访问量大:峰值可达每分钟数十亿次访问,尤其是在节日期间,用户高涨的热情更可以转化成平日三至五倍的访问量。同时具有冷热分明、读多写少 (读写比例甚至可达 100:1) 的访问特征,比如节日期间倍增的访问通常是对节日期间生成的新增数据的访问。下图展示了该集群访问在各时间段的一个占比情况;3原创 2020-08-04 16:44:16 · 319 阅读 · 0 评论 -
IM 架构设计05
从0到1的快速裂变:详解快的打车架构设计及技术实践原创 2020-08-01 20:06:13 · 193 阅读 · 0 评论 -
IM 架构设计04
微信后台存储架构原创 2020-07-31 23:42:39 · 227 阅读 · 0 评论 -
IM 架构设计03 读扩散 && 写扩散
https://blog.csdn.net/z50L2O08e2u4afToR9A/article/details/86746814系统通知,究竟是推送还是拉取?任何脱离业务场景的架构设计都是耍流氓。广义系统通知,有1对1的通知,以及一对多的通知,有相对实时的业务通知,以及能够容忍一定延时的系统通知。结合具体的场景来看下,这样的一些系统通知,究竟是推还是拉?一、系统对1的通知典型业务,计数类通知: 有10个美女添加了你为好友 有8个好友私信了你 很多业务经..原创 2020-07-29 20:44:51 · 2930 阅读 · 1 评论 -
IM 架构设计02
快速裂变:见证微信强大后台架构从0到1的演进历程(一)服务器把消息snapshot下发给客户端Svrkit是另一个广硏后台就已经存在的高性能RPC框架,当时尚未广泛使用,但在微信后台却大放异彩。作为微信后台基础设施中最重要的一部分,Svrkit这几年一直不断在进化。我们使用Svrkit构建了数以千计的服务模块,提供数万个服务接口,每天RPC调用次数达几十万亿次。图4是异步队列在群聊中的应用。微信的群聊是写扩散的,也就是说发到群里的一条消息会给群里的每个人都存一份(消息索引).原创 2020-07-28 12:14:53 · 217 阅读 · 0 评论 -
IM 架构设计01 基本介绍
携程早期IM架构四 发送流程消息的制造者[producer]一般是IM系统的最基本单元UIN[即一个自然人],既然是一个自然人,就认为其发送能力有限,不可能一秒内发出多于一条的消息,即其消息频率最高为: 1条msg / s。高于这个频率,都被认为是键盘狂人或者狂躁机器人,客户端或者服务端应该具有拒绝给这种人提供服务或者丢弃其由于发狂而发出的消息。基于上面这个假设,producer发出的消息请求被称为msg req,服务器给客户端返回的消息响应称为msg ack。整个消息流.原创 2020-07-27 12:10:42 · 528 阅读 · 0 评论