1.微信朋友圈

1.微信的架构

    1. 微信的架构和普通的架构差不多，最上面是终端通过接入服务器接进来。接入层主要是长连接，长连接主要四为了安卓系统，一个是减少建立新连接的性能消耗，另一个是为了推送通知，因为Google服务在国内基本是不可用的，安卓系统上的推送通知都是用长连接完成的。

2.微信朋友圈后台

2.1朋友圈数据的四个核心表

    1. 发布：发布数据记录了来自所有用户所有的feed，比如一个用户发布了几张图片，每张图片的url是什么，在cdn里的url是什么，他有那些属性，谁可以看，谁不可以看等等。 2. 相册：相册是每个用户独立的，记录了该用户所发布的所有内容。3. 评论。评论就是针对某个具体发布的朋友评论和点赞操作。4. 时间线：所有“刷朋友圈”，就是刷时间线，就是一个用户所有朋友的发布内容。注：由于每天的发布和浏览的数量过大，对性能的要求很高，所以存储都是做成可以水平扩展的。所谓的水平扩展：我们不是通过增加单个系统成员的负荷而是简单的通过增加更多的系统成员来实现。也就是说，假设有3辆卡车，每辆车一次可以运25根木材，计算花费1小时的情况下可以运送到指定地点等待处理的木材数量，通过这些数字我们可以算出我们系统最大的负荷量。水平扩展就是通过增加卡车的数量来运送木材。因此，当我们需要将负荷从75棵树每小时增加到150棵树每小时，那么只需要增加3辆卡车。

2.2朋友圈的工作流程（举例，对于水平扩展的实现）

       比如有两个用户小王和Mary。小王和Mary各自有各自的相册，可能在同一个服务器上，也可能不再同一个服务器上。现在小王上传了一张图片到朋友圈。上传图片不经过微信后台服务器，而是直接上传到最近的腾讯cdn结点，所以非常的快。图片上传到cdn后，小王的威信客户端会通知微信的朋友圈cdn：这里有一个新的发布（比如叫K2），这个发布的图片rul是什么，谁可以看到这些图片，等等此类的元数据，来吧则个发布写到发布的表里。  在发布的表写完之后，会把这个k2的发布索引写到小王的相册表里。相册的表很小，里面只有索引的指针，相册表写好了之后，会触发一个批处理的动作。这个动作就是去跟小王的每个好友说，小王有一个新的发布，请把这个发布插入到每个好友的时间线里面去。  此时Mary上朋友圈，而且Mary是小王的一个好友。Mary拉自己的时间线的时候，时间线会告诉到有一个新的发布K2，然后Mary的微信客户端就会去根据K2的元数据去获取图片在cdn上的url，将图片拉到本地。在这个过程中，发布是很重要的，因为一方面要写一个自己的数据副本。然后还要把这个副本的指针插到所有好友的时间线里面去。如果一个用户有几百个好友，这个过程会比较慢些。这是一个单数据副本写扩散的过程。但是相对应的，读取很简单，每一个用户只需读取自己的时间线就可以，不需要去遍历所有的好友的相册表。为什么选择这样一个写扩散的模型？因为读是有很多失败的，一个用户如果去读几百个好友的相册，极端情况下可能要去几百个服务器上去，这个失败的可能性是很大的。但是写失败就灭有关系，因为写失败是可以等待的，写失败就就重新去拷贝，知道插入成功为止。所以这样一个模型可以很大的减少服务的开销。赞和评论的实现。上面说了微信后台有一个专门的表存储评论和赞的数据，比如Kate是Mary和小王的朋友的话刷到K2这一条发布，就会同时从评论表里面拉去对应k2的、Mary留下的评论内容，插入到K2内容的下方，而如果另一个人不是Mary和小王的共同好友，就不能看到这个评论。

2.3朋友圈胖瘦分离

朋友圈包含的数据信息种类很多，文字、图片、视频、音乐，还有点赞与评论信息，提醒谁看，谁能看谁不能看等等。
为了方便处理，微信引入了“胖瘦数据”的概念，将视频、图片这些数据量大的信息称为胖数据，而文字，评论提醒（谁能可见，@信息）称为瘦数据，并将之分别处理。
瘦数据直接存储到微信后台（微信服务器端），而胖数据就要“出门左转”，在CDN中转一圈，瘦身为数据量很小的URL。这样就能一身轻松：当收到读取需求时，图片等胖数据就能直接从CDN中，依据URL来定位下载。

2.4数据存储

    存储层包括数据访问服务和数据存储服务。数据存储服务通过MySQL和SDB(广硏早期后台中广泛使用的Key-Table数据存储系统)等底层存储系统来持久化用户
数据。数据访问服务适配并路由数据访问请求到不同的底层数据存储服务，面向逻辑层提供结构化的数据服务。比较特别的是，微信后台每一种不同类型的数据都使用
单独的数据访问服务和数据存储服务，例如帐户、消息和联系人等等都是独立的。

2.新浪微博

1.第三代技术体系

    微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层；在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。下面是平台的整体架构图：

2.水平分层

1. 接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容（Feed）服务、用户关系服务及通讯服务（单发私信、群发、群聊）。
2. 服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都  属于这一类。图中使用泳道隔离，表示它们的独立性。另外一类为组合服务，通过各种原子服务   和业务逻辑的组合来完成服务，比如Feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。
3. 资源层主要是数据模型的存储，包含通用的缓存资源Redis和Memcached，以及持久化数据库存    储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务。水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。
与分层模型相对应，微博系统中的服务器主要包括三种类型：前端机（提供 API 接口服务）、队列机（处理上行业务逻辑，主要是数据写入）和存储
（mc、mysql、mcq、redis 、HBase等）。

3.服务层框架

    服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架。

4.MCQ消息队列

    1. 消息队列提供一种先入先出的通讯机制，在平台内部，最常见的场景是将数据的落地操作异步写入队列，队列处理程序批量读取并写入DB，消息队列提供的异步机制加快了前端机的响应时间，其次，批量的DB操作也间接提高了DB操作性能。2. 微博平台内部大量使用的MCQ(SimpleQueue Service Over Memcache)消息队列服务，基于MemCache协议，消息数据持久化写入BerkeleyDB，只有get/set两个命令，同时也非常容易做监控（stats queue），有丰富的client library，线上运行多年，性能比通用的MQ高很多倍。

5.Motan RPC框架

        微博的Motan RPC服务，底层通讯引擎采用了Netty网络框架，序列化协议支持Hessian和Java序列化，通讯协议支持Motan、http、tcp、mc等，Motan框架在内部大量使用，在系统的健壮性和服务治理方面，有较为成熟的技术解决方案，健壮性上，基于Config配置管理服务实现了High Availability与Load Balance策略（支持灵活的FailOver和FailFast HA策略，以及Round Robin、LRU、Consistent Hash等Load Balance策略），服务治理方面，生成完整的服务调用链数据，服务请求性能数据，响应时间（Response Time）、QPS以及标准化Error、Exception日志信息。

6.SSDCache

    微博平台将SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为 Redis/MC + SSD Cache + Mysql方式，SSD Cache作为L2缓存使用，
第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力。

注：工作中用到的从别人那里整理过来的具体的博客记不清了