《App后台开发运维和架构实践》读书笔记 - 案例

第9章  案例

9.1 聊天App

9.1.1 移动互联网2个特性：

1. 弱网络性：不稳定，经常断；App和服务器之间的长连接会经常断开，App没法主动通知服务器自己已断开，导致:1. 服务器资源占用; 2. 收发消息异常；这叫“TCP half-
4000
open”

- 解决：App定时向服务器发心跳消息；服务器端检验超时，有3种方式：

a. 服务器端按时扫描所有连接，发现超时的就主动关闭释放资源。缺点是扫描很多很多连接太耗时；

b. 每个连接设置定时器，每次心跳来了就重置定时器，定时器被触发则关之。缺点是定时期太多占资源大；

c. 时间轮片(Timing Wheel), 把超时间隔T分成N桶，每隔T/N时间就顺时针取下一个桶，将里面的所有连接都关闭掉；当一个连接收到心跳时，就把他从当前桶取出，放到队尾的桶里去；优点：不需要扫描所有连接，扫描的都是真正要关闭的连接！



2. 流量敏感：App耗流量太大，用户会卸载之；

9.1.2 协议

XMPP: 基于XML的消息协议；成熟，用得多；Gtalk, facebook用之；缺点：耗费流量；开源聊天服务器：Ejobberd(Erlang实现), Openfire(java实现)

类ActivitySync: 微信用之，省流量，性能高；缺点：没有现成的实现，需要自己实现；

解决TCP接收端缓冲区内相邻包无法辨别边界的问题（粘包问题）：1. MySQL协议；2. Redis协议(陌陌使用)

- 处理丢包：

a. 每发送一个消息，对方都要发一个确认消息过来；缺点：网络中端，可能造成消息重发；每次都握手延迟大；

b. 基于版本号：每个消息都有一个递增的版本号；网络重新连上时，或者一段时间后，App向服务器发送“同步消息”，告知自己上次接收到的最新版本号；服务器向其发送该版本号之后的所有消息；优点：发许多消息只需要一次同步；微信，陌陌用之；

- 发送图片声音等大消息：

使用“文件服务”做中转：1. 用户a发送图片至"文件服务"；2. 文件服务返回URL给用户a；3. 用户a发送文字消息给“聊天后台”；4. “聊天后台”发送文字消息给用户b；5. 用户b将URL发给"文件服务"请求图片; 6. "文件服务"返回图片给用户b

"文件服务"做中转的优点：1. App和"聊天后台"只处理文字，简化实现；2. 所有文件放在"聊天服务"中，便于统一优化性能（云存储或者CDN等）

9.1.3 架构

连接层：连接服务器集群

业务层：验证模块；路由模块；统计模块；数据存储模块；

持久层：数据持久化服务

连接服务器：

- 若想重启，要提前主动通知其上的所有连接那头的App们，让他们马上去连接别的连接服务器去；

- 多台服务器，App连接哪个？：有一台DNS服务器，根据连接服务器集群负载情况，动态分配一台连接服务器给每个App；

- 若DNS服务器某时刻连不上怎么办？：在App里面预埋，设置默认的连接服务器，应急用；

连接层和业务层之间， 使用队列来传递消息，便于解耦和，即彼此的短时重启不会丢失消息或者卡住对方，因为消息都暂存在队列里；

参考资料：

讲师：李志威 《高可用即时通信架构》

微信技术总监周颢：一亿用户背后架构秘密 http://tech.qq.com/a/20120515/000224.htm

9.2 社交App（微博）

9.2.1 表结构：

- 发送内容表：feed_id, author_id, content

- 接收内容表（推模式才有）：feed_id, author_id, receive_id, content

- 关注表：user_id, following_id  (user_id关注哪些following_id)

- 粉丝表：user_id, follower_id  (user_id被哪些follower_id所关注)

9.2.2 推拉模式：

1. 推模式：用户A每发一条内容，就会将其复制到他的所有粉丝的“收件箱”里面去；优点：显示得快；缺点：占空间，推送动作慢（粉丝多的时候），删内容动作麻烦；

2. 拉模式：用户的每条内容只存储一份；显示的时候即时去关注表里找所有关注的人，把他们最近发表的内容全拉取过来，merge;  优点：存储占用小，变更操作容易；缺点：显示时延时较大，需要大量拉取和merge操作；可使用缓存来加速；

微博：公开的微博用的拉模式； 私密的微博用的推模式

9.2.3 数据库架构

业务层分库分表：（注意id一致）

- 按hash拆分；优点：最常用，增长速度可控；缺点：冷热数据没法分离存取；

- 按时间先后拆分：每个时间段，放在一张表里；优点：近期数据热，早期数据冷，分放在内存SSD磁盘等不同存储中；缺点：访问太集中（都集中在近期数据表上）

- hash和时间拆分结合：二维矩阵，hash是一维，时间是一维；既可冷热分离，又负载均衡；一般先hash到子库，再按时间放到子表；

加速：二级索引；

9.2.4 缓存架构演进

1. 分布式缓存：单台内存不够，就用多台；hash到对应机器上；

2. 一致性哈希：增加机器和下线机器，造成所有数据hash到新机器上，开销巨大；解决：一致性哈希，增加和删除机器只影响小段hash区间会变动机器；

3. 带多个虚拟节点的一致性哈希：解决普通一致性哈希负载均衡差的问题；

4. 宕机问题解决：主从缓存；主缓存数据定期同步到从缓存，或者，一定概率的请求落到从缓存上，使从缓存数据不过冷；

参考资料：

洪小军 大中型SNS系统设计漫谈

9.3 LBS App

9.3.1 地理坐标：每个坐标系是不同的

9.3.2 查找附近的人

建议使用MongoDB; 自带LBS功能支持，搜索附近的坐标；

9.3.3 MongoDB分片：按用户所在区域来划分到不同的分片里；（一线城市用户多，为一个分片；二线大城市一个分片；其他地方一个分片；分片内部计算“附近坐标”不需要使用别的分片！）

其他资料：

1. InfoQ (http://www.infoq.com/cn)

2. 七牛开发者最佳实践日

3. UPYUN Open Talk

4. 微信公众号"高可用架构" （微信号：ArchNotes）

5. 新浪微博 @微博平台架构