即时消息技术剖析与实战
袁武林
微博研发中心技术专家
立即订阅
6503 人已学习
课程目录
已完结 24 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 搞懂“实时交互”的IM技术,将会有什么新机遇?
免费
基础篇 (8讲)
01 | 架构与特性:一个完整的IM系统是怎样的?
02 | 消息收发架构:为你的App,加上实时通信功能
03 | 轮询与长连接:如何解决消息的实时到达问题?
04 | ACK机制:如何保证消息的可靠投递?
05 | 消息序号生成器:如何保证你的消息不会乱序?
06 | HttpDNS和TLS:你的消息聊天真的安全吗?
07 | 分布式锁和原子性:你看到的未读消息提醒是真的吗?
08 | 智能心跳机制:解决网络的不确定性
场景篇 (4讲)
09 | 分布式一致性:让你的消息支持多终端漫游
10 | 自动智能扩缩容:直播互动场景中峰值流量的应对
11 | 期中实战:动手写一个简易版的IM系统
12 | 服务高可用:保证核心链路稳定性的流控和熔断机制
进阶篇 (10讲)
13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考
14 | 分片上传:如何让你的图片、音视频消息发送得更快?
15 | CDN加速:如何让你的图片、视频、语音消息浏览播放不卡?
16 | APNs:聊一聊第三方系统级消息通道的事
17 | Cache:多级缓存架构在消息系统中的应用
18 | Docker容器化:说一说IM系统中模块水平扩展的实现
19 | 端到端Trace:消息收发链路的监控体系搭建
20 | 存储和并发:万人群聊系统设计中的几个难点
21 | 期末实战:为你的简约版IM系统,加上功能
22 | 答疑解惑:不同即时消息场景下架构实现上的异同
结束语 (1讲)
结束语 | 真正的高贵,不是优于别人,而是优于过去的自己
即时消息技术剖析与实战
登录|注册

18 | Docker容器化:说一说IM系统中模块水平扩展的实现

袁武林 2019-10-07
你好,我是袁武林。
第 10 讲“自动智能扩缩容:直播互动场景中峰值流量的应对”中,我较为系统地讲解了直播场景中突发流量的应对策略。其中比较重要的一点就是:当有热点流量进来时,我们能够通过监控指标对服务进行快速扩缩容。
而快速扩缩容的一个重要前提,就是部署的服务和资源能够做到水平扩展。
那么,今天我们就来聊一聊服务和资源水平扩展的实现问题。

垂直扩展

首先从水平扩展 (Scale out) 的概念说起吧。
要解释水平扩展是什么,我们要先了解下与水平扩展相对应的另一个概念:垂直扩展(Scale up)。只有通过这两者可行性和实现层面的对比,我们才能更好地理解为什么水平扩展能力对于实现一个架构良好的系统如此重要。
当业务的用户量随着产品迭代不断增长时,相应的后端资源和服务器的压力也在逐渐加大。而解决资源和服务器瓶颈一个有效且较快的方式就是:提升资源服务器和应用服务器的单机处理能力,也就是对资源服务器和应用服务器进行“垂直扩展”。

提升单机硬件性能

要对资源和服务进行垂直扩展,一个简单粗暴但也比较有效的方式就是:增强单机服务器的性能。
比如:对 CPU 出现瓶颈的服务器进行升级,增加 CPU 核数和主频;对于网卡有瓶颈的服务器,升级到万兆网卡并接入到万兆交换机下;内存出现瓶颈导致系统吃 Swap 的情况,我们也可以将内存升级到更高配置来进行垂直扩展。一般情况下,通过对服务器硬件的升级,往往能快速解决短期的系统瓶颈问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《即时消息技术剖析与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • leslie
    老师:目前有没有什么不错的开源IM项目可以学习和研究?

    作者回复: 可以看看mqtt的github项目,另外国内应该蘑菇街开源了一款叫teamtalk的im软件,也可以看看。

    2019-10-07
    6
  • 东东🎈
    老师,如果遇到ddos攻击,有啥处理方案吗?

    作者回复: 硬件层面可以上硬件防火墙来清洗异常流量,软件层面可以通过缩短syn半连接的超时来缓降。

    2019-10-07
    3
  • A:春哥大魔王
    老师的课程应该是最近半年极客时间最棒的啦!其他的竟是些概念理论的泛泛而谈😜

    作者回复: 欣慰,感谢支持,继续努力~

    2019-10-07
    1
    3
  • QQ怪
    可以分库分表来解决单表写入数据量大,查询时间过长,但实现其复杂性也增加了,需要实现分区键或者说以什么依据来进行分库分表

    作者回复: 嗯,分库分表是一个有效提升写入能力的手段,除了这个还有其他优化方式吗?

    2019-10-07
    1
    2
  • Jun
    是否可以先在服务器端聚合一段时间的数据再写入

    作者回复: 嗯,不错的想法,业务允许一定的风险的话这是一个不错的优化手段。

    2019-10-11
    1
  • 面爸
    人数统计的话,应该用redis就可以实现,写入的话,可以队列,异步去写

    作者回复: 嗯,redis作为计数没问题的,不过异步写入只是起到削峰填谷的作用,并不能提升写入的绝对能力,可以再想一想哈

    2019-10-07
    1
  • HelloTalk
    要想解决资源层的写入瓶颈,除了分片机制外,还可以移步写 用队列来操作

    作者回复: 是个方案,不过队列更多起到的是削峰填谷的作用,对写入瓶颈的真实写入能力提升有限。

    2019-10-07
    1
  • 于欣磊
    分表 存贮 对于一些热点列 在cache里面增加特殊索引字段 也可以在内存中 直接存储计算结果 节省 查询 计算时间
    2019-12-04
  • GeekAmI
    请问老师:长连网关调用业务层为何是RPC,而不是通过消息队列调用呢?

    作者回复: 如果发送消息是否成功依赖于消息存储是否成功,而消息存储的逻辑在业务层,那么发消息需要业务层明确告知是否存储查成功,这种情况rpc通过response明确告知网关层是否成功实现上更方便。

    2019-11-12
    1
  • 唯我天棋
    要想解决资源层的写入瓶颈,除了分片机制外,还有什么办法能解决资源写入瓶颈的问题呢(比如直播间观看人数的计数资源)?

    1.使用高性能缓存。。
    2.请求合并
    2019-11-04
  • 唯我天棋
    1.连接层和业务层之间增加一个业务代理,这样连接层可以更加专注于处理连接问题,让业务代理来完成服务发现,管理业务集群,这样会不会更好?
    2.为什么在连接层直接rpc调用业务端。那业务端需要通过这条连接推送消息不是会很不方便吗?

    作者回复: 服务发现本身是rpc框架自带的通用特性,对系统消耗很小,再增加一层会使消息收发链路变长,整体稳定性可能会有影响。
    业务层推送消息是通过消息队列来实现的,不需要依赖rpc。

    2019-11-04
  • 黄海
    请问老师,课程中的 tcp长连接网关机,可以用 openresty 开发吗?

    作者回复: 对openresty了解不多,据我所知openresty主要是对标nginx的吧,tcp连接相关的信息不知道是否会暴露给使用者,另外即使可以长连接基于它实现可能得大量的lua嵌入开发吧,实现上可能会比较困难。

    2019-10-13
  • 老师问题:单位时间时间内如何提高写入速度
    垂直方向:
    1、sql语句优化,索引,事务写入
    水平方向:
    1、分库分表
    2、读写分离
    直播观看计数资源,不是要保存在关系数据库,可以考虑用nosql非关系数据库
    2019-10-10
  • clip
    用分片来做水平扩展的话灵活性是低的吧,是不是不适合随着每天波峰、波谷来调整?感觉只能扩很难收。
    如果某个时段有大量写入,用什么方式应对比较合适呢?

    作者回复: 跟随流量波动来进行资源层的扩缩容对于数据读取可能比较有效,但是对于数据依赖master的写入扩缩容实现会比较麻烦。对于写入的优化可以采用类似操作系统buffer的机制,来对写入数据进行合并后批量写入,甚至根据业务来进行更高级的定制化合并逻辑。这一块我在第20篇万人群聊系统的设计中会讲一下。

    2019-10-09
  • 东东🎈
    老师,线上netty经常抛java.io.Exception:Connection reset by peer异常,连接被重置,这个问题可以修复吗?

    作者回复: 这个是由于对端客户端关闭连接时发送的是强制关闭连接的rst包而不是正常关闭的fin包,注意观察客户端是否对应的有crash的情况出现,一般对服务端连接层没啥影响。

    2019-10-08
    1
收起评论
15
返回
顶部