极客时间-即时通讯学习笔记
2020-03-25 09:39:54 6 举报AI智能生成
即时通讯关键技术脑图
作者其他创作
大纲/内容
即时通讯学习思考
Point
tio https://www.t-io.org
https://www.techempower.com/benchmarks/#section=test&runid=8aaf581a-45f8-4d19-bb49-95c7900b8ce3&hw=ph&test=plaintext&l=zik0vz-v
wireshark抓包工具
接入服务与业务处理服务拆分的理由
业务处理服务经常上线，不应影响接入层长连接状态
业务开发门槛降低，开发人员不需要了解连接和协议部分
IM系统有哪些特征
实时性
实现机制
短轮询
长轮询
TCP
WebSocket
XMPP
MQTT
Socket
可靠性
不丢消息
消息不重复
消息完整性检查策略
根据服务器端时间戳
全局递增版本号
一致性
消息有序
找到时序基准
发送方本地序号或者本地时钟
时钟用户可随时调整，回退
本地序号随着重装应用会清零
群聊，多点登陆场景不适用
后端服务器本地时钟
NTP时钟同步 毫秒级误差 勉强够用
全局序列号生成器
Redis原子自增incr
单点问题
snowflake算法
精度有限秒级或毫秒级
服务器本地时间时钟不一致问题
分布式序号生成服务
基于单聊会话和群聊会话的独立id生成器
不追求全局递增，只追求会话内递增
消息推送整流
安全性
数据传输安全
访问入口安全
HttpDNS解决DNS劫持问题
传输链路安全
应对措施
中断
多通道切换：HttpDNS返回多个接入IP，前端切换
多协议切换：比如从基于 UDP 协议的 QUIC 协议切换到基于 TCP 协议的私有协议；或者针对 TCP 的私有协议提供 HTTP Tunnel 来对数据进行二次封装
截获/篡改/伪造
私有协议
TLS
非对称加密算法和秘钥交换算法用于保证消息加密的密钥不被破解和泄露。
对称加密算法对消息进行加密，保证业务数据传输过程被截获后无法破解，也无法篡改消息。
数字签名和 CA 认证能验证证书持有者的公钥有效性，防止服务端身份的伪造。
中断：切断网络
截获：窃取传输内容
篡改：篡改传输消息内容，破坏消息完整性和真实语义
伪造：伪造正常消息模拟正常用户或服务器请求
数据存储安全
账号密码存储安全：“单向散列”算法
消息内容存储安全：端到端加密
消息内容安全
建立敏感词库，针对文字内容进行安全识别
依托图片识别技术来对色情图片和视频、广告图片、涉政图片等进行识别处置
使用“语音转文字”和 OCR（图片文本识别）来辅助对图片和语音的进一步挖掘识别
通过爬虫技术来对链接内容进行进一步分析，识别“风险外链”
经典问题
会话消息未读数&总未读数
保证未读更新的原子性
分布式锁
DB唯一键约束
MC的add
Redis的setNX
缺点
降低吞吐
锁管理容易出现BUG
资源单点问题
锁最终能释放问题
支持事务功能的资源
Redis 通过 MULTI、DISCARD 、EXEC 和 WATCH 四个命令来支持事务操作
乐观锁策略导致变更频繁时执行效率低
原子化潜入脚本
Redis 支持通过嵌入 Lua 脚本来原子化执行多条语句
Redis cluster集群模式lua脚本如果操作的两个key不在同一个节点，会报异常。需要使用lua的数据需要确保两个key能hash到一个节点
Redis的事务实际上需要使用方自行处理失败的后续操作
心跳检测的实现方式
TCP Keepalive
默认的三个配置项：心跳周期是 2 小时，失败后再重试 9 次，超时时间 75s。三个配置项均可以调整。
操作系统默认是关闭这个特性的，需要由应用层来开启
固定间隔，灵活性较差，无法反应应用层服务状态
应用层心跳
固定间隔心跳
智能心跳
直播场景下聊天，高并发压力的挑战
消息扇出从逻辑层下沉到接入层
消息的发和收从接入层到业务处理层都进行隔离拆分
上行消息http短链接
下行消息TCP长连接
流量控制
漏桶算法
控制数据注入到网络的速率，平滑网络上的突发流量
令牌桶算法
控制的是一个时间窗口内通过的数据量
可以使用原子性的、线程安全的数据结构来存储令牌，比如AotomicLong等，这种数据结构支持一次decr多个而且能保证线程安全和高性能的
全局流控
通过中央式的资源（如：Redis、Nginx）配合脚本来实现全局的计数器，如Redis+Lua
细粒度控制
流控依赖资源瓶颈，如redis扛不住了
可以通过“本地批量预取”的方式来降低对资源的压力
自动熔断机制
Hystrix
Resilience4j
多级缓存
高并发的三板斧
缓存
常见分布式算法
取模求余
一致性哈希
带虚拟节点的一致性哈希
多级缓存架构
主从模式
无法解决热点问题
L1+ 主从模式
本地缓存 +L1+ 主从的多层模式
对于本地缓存的数据一致性问题，我们可以通过“短过期时间”来平衡缓存命中率和数据一致性。
降级
限流
扩展能力
垂直扩展
硬件性能提升：CPU，内存，网卡
进程处理能力提升：扩大线程数，增加使用内存，使用本地缓存，压缩数据节约带宽
水平扩展
接入层的水平扩展
LVS接入层：DNS轮询
应用接入层：将用户在线状态维护在中央缓存中如redis
业务层水平扩展
通过RPC框架如Dubbo来支持
资源层水平扩展
读取：增加从库、增加 L1 缓存、应用层支持本地缓存
写入：分片
复杂网络环境下通道高可用
让消息通道能连得上
多端口访问
尽量使用知名端口，业界确认比较安全的端口基本上只有 80、8080、443、14000 这几个
同时使用多个端口
HTTP Tunnel
有些网络环境下只允许HTTP协议访问外网，TCP或UDP实现的私有协议不通
HTTP Tunnel就是在私有协议外面用Http做了一层封装
多接入点IP列表
后端返回多个接入IP
前端预埋保底IP或保底域名
让消息通道连得快
跨运营商网络延迟
多运营商机房部署
HttpDNA精确解析用户出口网关IP 进行调度
跑马竞速
客户端本地对IP列表测速并上报服务测速结果，后端动态调整IP权重
让消息通道保持稳定
通道和业务解耦
业务频繁变更不应影响长连接通道
上下行通道隔离
上下行消息流量较大时
TCP双工通讯如何解决双向负载较重时的冲突？
多媒体文件独立上传下载
上传提速
智能DNS分运营商接入上传服务
多线BGP：允许同一 IP 在不同运营商网络中广播不同的路由信息
上传通道与tcp长连接通道隔离（和现在微店iM做法相同）
分片上传
动态调整：腾讯内部的“鱼翅”项目，就是通过算法来动态调整分片大小
断点续传
秒传
比较文件哈希值，存在已存在文件则无需重复上传直接下发；避免哈希冲突，使用多种单向 Hash 算法，在都一致的情况下才判断为重复。
下载提速
CDN加速
使用模式
拉模式：就近节点无缓存则去源战拉取
预热模式：提前强制 CDN 节点回源并获取最新文件
预热速度能否保证？
私密性
CDN不提供精细化权限控制，单聊场景图文资源不适合放到CDN
源站鉴权
短时间戳防盗链
有隐私要求且要上CDN的资源自行加密
HLS（流媒体网络传输协议）
播放器改造，支持自定义的加密方式
边下载边播放
前提条件
格式信息和关键帧信息在文件流的头部
服务端支持 Range 分片获取
一种是文件的存储服务本身支持按 Range 获取
对于不支持分片获取的存储服务来说，还可以利用负载均衡层对 Range 的支持来进行优化
图片压缩和视频转码
分辨率自适应
WebP 和渐进式 JPEG
H.265 转码
预加载
推流
推送
APNs
DeviceToken过期时机
IOS系统升级
APNs服务端禁用或老化
Payload大小限制
iOS 8 之前是 256B
iOS 8-10 是 2KB
iOS 10 以后 是 4KB
标题正文
IOS 10 之前只有文本正文
IOS 10 之后支持主标题、副标题，还能支持附件
静默推送
IOS 7 之后支持，静默唤醒APP
槽点
可靠性低 实时性和到达率无法保证
离线消息QoS策略只保存最后一条消息
计数角标只覆盖不累加
GCM
厂商通道
第三方通道（信鸽/个推/极光）
职业：暂无
0 条评论
回复 删除
下一页
