微信、陌陌等著名IM软件设计架构详解( 三 ) _架构

4、复杂网络
－2G，3G，4G，wifi 。cmwap，cmnet 。。
－网关限制：协议，端口
5、用户流动性大，上网环境复杂
WNS 性能指标：

文章插图

文章插图

1、开发时间：历史一年半
2、链接成功率－99.9%
3、极端网络环境下成功率－由于常见app
4、crash率－0.02%（crash次数／登录用户数）
微信后台系统架构
背景：
A、分布式问题收敛
后台逻辑模块专注逻辑，快速开发
可能读取到过时的数据是个痛点
需要看到一致的数据
B、内部定义
数据拥有两个以上的副本
如果成功提交了变更，那么不会再返回旧数据
推演：
1增加一个数据
2 序列号发生器，偏序
约束：只能有一个client操作
client有解决冲突的能力
问题转移：client如何分布？
3 修改集群中一个制定的key的value
1）覆盖他
2）根据value的内容做修改
if value ＝ 1 then value ：＝2
通用解法：
1）paxos算法
工程难度
一切可控
分布式算法设计：
2）quorum算法（2011）
再单个key上面运算
真是系统约束
类paxos方案，简化
为每次变更选举（by key）
算法过程
提议／变更／同步／广播
系统架构

文章插图

写流程
Replication & Sharding
权衡点
自治，负载均衡，扩散控制
replication－>relation
容灾抵消
同城（上海）多数派存活
三园区（独立供电，独立）
Sharding
一组KV6 为一个单位
1、人工阶段
局部扩容，影响收敛9
2均匀分布制定分段hash32 （string）
翻倍扩容
3一致性哈希
具体实现？
1、业务侧快速开发
存储需要提供强一致性
丰富的数据模型支持（结构化、类SQL／KV）
条件读，条件写
2 业务增长迅速，系统要能够方便的横向扩容
3设备故障／短时节点实效便成为常态，容灾自动化，主碑可写无需人工介入
4小数据
存储模型
纯内存
Bitcask
小表系统
LSM－tree

文章插图

小表系统
1、解决放大问题
2、数据按变更聚集存储
3、Affected1
ChangeTable
（1＋2+ 。。。。＋n－1+total）／n
4、分裂与合并
数据流动
1、自动化迁移
2、节点同时做代理
3、合并磁盘io
同步流量
1、数据vs 操作
2、幂等
3、保底策略
通信包量
1、动态合并
100K qps
200% －10%
3、权衡与估算
设计要点
1、吞吐量
2、异步化
3、复杂度
4、libco
自动修复系统
1、不要让错误累计
2、全量扫描
bitcask 的一些变化
1、内存限制
2、全内存