微博技术架构

第一版架构

1. 是LAMP架构，优点是可以很快地实现系统，第一版采用推消息模式，假如明星用户有10万粉丝，当用户发表一条微博的时候，把微博消息存成10万份，使用的是MyISAM搜索引擎，优点就是速度很快。
2. MPSS，多个端口可以布置在同一个服务器上。
3. 假如做一个互联网应用，应用里面有三个单元，可以有两种部署方式。第一种部署方式是把三个单元分别部署在三台服务器上，第二种部署方式是在三台服务器的每台服务器上都部署上这三个单元。推荐第二种部署方式。
4. 上面的第二种部署方式解决了两个问题：第一个问题是负载均衡，第二个问题是避免单点故障。负载均衡体现在：每一个单元都有多个节点处理。避免单点故障体现在：任何一个节点发生故障对于整体都不会影响。

第一版架构遇到的问题

1. 发表会出现延迟。推模式是出现延迟的首要原因。
2. 第一版架构是单库单表，当用户数量激增时，需要拆分。
3. 锁表的问题，更换引擎。
4. 发表过慢，考虑异步模式。

第二版架构

1. 考虑模块化。
2. 首先做分层，最底层叫做基础层。
3. 然后是服务层，把微博的基础单元设计成服务层的一个一个模块。
4. 对数据做拆分。数据的拆分有很多方式，比如按照用户的UID来拆分。这里结合微博的特点：微博用户一般都是查看最近的消息，所以这里可以按照时间来拆分，比如一个月放一张表。
5. 数据拆分的第二点需要考虑将内容和索引分开存放，索引和内容分开存放那么数据就会变成key-value的方式，key-value是最容易扩展的一种数据。
6. 索引的拆分面临的挑战是：比如用户发表了1000条微博，这些微博前端需要分页访问，如果用户需要访问哪一页，需要快速定位。
7. 如果把索引按月拆分，一个月一张表，那么很难知道某一页在哪张表里。解决办法是在索引上做二次索引，把每个月的索引的偏移记录下来，知道每个月用户发表了多少条，通过这样可以知道某一页在哪张表上。
8. 对发表采取异步模式。发表是繁重的操作，需要入库，统计索引，进入后台。并且如果其中有某个环节失败，但是入库发生在第一步，是成功的，那么用户得到的提示是发表失败，但是入库成功，造成数据不一致。解决办法：对发表采取异步模式，只有发表成功用户才会收到成功的消息。一系列操作不需要同步执行，而是交给消息队列在后台异步执行。
9. 改进推模式，对投递模式的优化。把用户分为有效用户和无效用户。比如用户有1000个粉丝，发布消息时不需要同步推给1000个粉丝，因为可能有400个粉丝不会马上来看，所以如果同步推送给这400个粉丝，相当于做无用功。
10. 怎样区分有效用户和无效用户，这里把当天登录的人称为有效用户，其余为无效用户。

第二版架构的问题

1. 单点故障造成的雪崩。
2. 访问速度带来的问题。
3. 数据压力以及峰值。将数据拆分，进行容量规划。
4. MySQL复制延迟。
5. 慢查询。
6. 热门事件。系统要能允许任意模块失败，静态内容使用CDN来加速。
7. 开放平台的需求是有差异的，web系统有用户行为才有请求。但是API系统特别是客户端的应用，只要用户一开机就会有请求，直到用户关机。

第三版架构

1. 考虑的是先有服务再有接口，再有应用。
2. 把底层分成基础服务，基础服务里有分布式的存储，去中心化。
3. 基础服务数据库冷热分离、多维度拆分。不同的业务不同的考虑，对于私信按照UID来拆分比按照时间拆分更高效。
4. 在基础服务上面有平台服务，把微博常用的应用做成小的服务，然后还有应用服务，应用服务是考虑平台各种应用的需求，最上面是API，是各种第三方应用在跑。
5. 平台服务与应用服务分开，实现模块隔离。
6. 实现分层关系，用户的关注关系，改成多维度的索引结构。
7. 计数器的改进，基于偏移的思想，原来的计数采用的绝对计数。比如某用户原来读到的ID是10，现在系统最新的ID是12，那么可以知道有2条未读。原来是存储的绝对计数值，那么就很容易造成数据一致性问题。
8. 动态内容支持多IDC同步更新。

如何做到低延迟、高可用、以扩展、、高实时性

1. 模块设计上要去状态，任意一个单元可以支持任意节点。
2. 去中心化，避免单点。
3. 可线性扩展。
4. 减少模块。
5. 实时性的核心在于让数据距离CPU最近，淘宝专家余锋说，CPU访问L1就像在书桌拿一本书，L2是从书架拿一本书，L3是从客厅桌子拿一本书，访问主存是从社区图书馆拿书。
6. 这里把用户随时访问的数据称为INBOX，这类数据需要放在离CPU最近。OUTBOX里面最近发表的数据存储在L1cache。最后一部分内容体有三部分，L0是本地的，把需要经常访问的，比如明星的微博内容体本地化，L1存放最近发表的，L2存放中期数据。
7. 实现高可用性，需要做好监控以及入口的管理，某服务若访问量过了的话，那么需要有开关可以阻止。还有接口监控，包括访问错误失败率，监控的指标要尽量量化。
8. 大型系统需要将一切自动化，因为人是会经常出现操作失误的，比如发布、安装、服务、启用、停止。谷歌工程师会把上一周遇到的问题用程序来解决，这样下次遇到同样问题一个按钮就可以解决了。
9. 异地分布。在国内网络环境下，IDC（Internet data center互联网数据中心）灾难，机房检修、机房掉电，所以每个服务单元都支持多机房部署，多机房部署后，用户的访问速度也会提高。多IDC静态内容分布技术已经很成熟了，动态内容的CDN分布是难点（CDN节点分布，CDN是content delevery network内容分发网络），核心是分布式存储，分布式存储需要满足：海量规模、可扩展、高性能、低延迟、高可用、多机房分布、异地容灾能力。
10. 分布式存储需要做到多对多的数据复制，数据复制有三种策略：第一种：master/slave。存在缺点：master是中心化的，如果master在北京，那么广州的访问会慢，存在延迟。 不采用。
11. 数据复制的第二种：multi-master，使用这个方案只需要避免冲突，对于微博这个应用可以做到，用户不会同时在北京和上海两地同时发表微博或者修改资料。采用。
12. 数据复制的第三种：Paxos一致性算法，达到强一致写。一条数据如果成功肯定是所有机房都成功了。缺点是延迟性很大。不采用。

多机房同步方案：

1. 前端应用将数据写到数据库，通过消息代理，将数据广播到多个机房，通过消息广播方式将数据多点分布，消息交给代理，代理把消息同步到多个机房。
2. 采用消息代理的好处：第一是数据提供后没有写到数据库是不会消失的。YMB是消息代理的产品。
3. API的大部分请求都是为了获得最新的数据，API请求的特点：大部分请求都是空返回的。例如手机客户端每隔一分钟不管服务器有没有数据都要调用一次，如果这次调用到下次调用之间有新数据，是不会知道的。解决办法：改为推的方式，不需要客户端每隔一定时间去调用拉取。服务端的连接是高并发长连接。推模式：低延时。

推送模式做到实时性

1. 微博在发布后，放在消息队列里，然后消息队列处理程序进行处理，处理后放到数据库。
2. 为了保证数据不丢失，需要对数据持久化，做持久化这个操作是可以进行的，是经过测试验证的，推送整个流程做到100毫秒到200毫秒之间，即使做持久化也可以在这个时间段把数据推送出去。
3. 内部细节：收到数据后要经过最上面的RECEIVER，推到引擎里面，引擎会做两件事，取到用户关系，把消息推送给用户的粉丝，需要唤醒操作，在接口把调用方唤醒，然后再推送过去。高并发的长连接服务器，一台服务器支持10万以上的高并发连接，需要Stream Buffer保存用户最近的数据，因为用户有可能会断线，如果发送数据的时候用户断线半分钟，那么需要推送架构补充这半分钟给它。

平台安全部分

1. 接口完全开放，需要防范恶意行为。通过接口发送垃圾信息以及刷粉丝。
2. 安全架构做了三件事：第一件：实时处理，根据频度、内容的相似性来判断发的是否是广告或者垃圾信息。第二件：日志处理器，是一个离线纠正模块，根据行为进行判断，比如说某用户潜伏几个月后开始发广告了，事后把这些人清理掉。第三件：通过监控。
3. 接口需要清晰安全的规则，从一个APP调用微博接口，按照业务模块划分阶层，安全层、权限层，接口安全和内容安全。

总结

1. 微博第一版架构解决发布规模问题，第二版解决数据规模问题，第三版解决服务化问题。
2. 添加链接描述