架构知识

人人网架构1

引用

MySQL
关系型数据库存储系统，我们的DBA团队很强大，每人管理上百台MySQL服务器，其他就不多说了，网上资料太多了

Tokyo Cabinet
一个key-value的存储引擎，日本人开发，国内很多公司也开始使用，我们内部很多地方也用它来代替MySQL来做存储，比如我们的搜索结果页的用户资料，就是用它来做一层MySQL外的冗余存储，目的是加快搜索结果页的显示。在key-value并需要持久存储的场景下，用它比MySQL更有效，Cabinet本身只是一个存储引擎，没有网络处理能力，你可以用它作为自己的某个系统的下层存储引擎，更好的是搭配Tokyo Tyrant使用。

Tokyo Tyrant
一个支持Memcached传输协议的网络接口，由Tokyo Cabinet的作者开发，目的是为Tokyo Cabinet提供网络接入能力，即Tokyo Tyrant处理网络连接，协议解析，然后调用Tokyo Cabinet的API来完成持久化存储。

ICE
一个跨语言的网络通讯框架，框架本身提供了强大的通讯能力，管理工具，负载均衡方案，其跨语言能力也是一个很大的亮点，基于这个框架之上，我们选用合适的语言来提供合适的服务，比如我们使用C++来开发Cache服务，使用Java来开发一些逻辑服务。框架本身可以很重，也可以很轻，具体要看你怎么用：）

Memcached
一个纯内存的key-value的cache系统，高效、稳定，使用广泛，如果你连它都没听说过就太out啦，memcached本身不具备分布式能力，需要依靠Client来实现分布，这里强调一点的是，你应该选择一致性Hash来做key的分布。各种语言的client都有，我们使用spymemcached作为java的Client，spymemcached是一个异步的NIO的memcached client，对网络IO的处理非常的精巧，也更加高效，同时因为提供异步操作方式，可以让你对Memcached的操作有更好的控制能力，Memcached到1.4.0版本之后，开始支持binary protocol，spymemcached对其也支持的比较好，使用binary protocol可以提高对协议的解析效率和网络IO的读写效率。
上面说到我们使用ICE自己开发了Cache服务，为什么我们还要用Memcached呢？主要在对Cache的操作粒度不一样，Memcached对Cache对象以binary byte作为一个整体来操作，需要频繁的序列化和反序列化，我们使用ICE提供的Cache服务，可以以Cache对象的一个或者多个字段来操作，比如一个用户对象，我们可以只更新它的姓名，而Memcached

Nginx
高效、稳定的Web Server，我们利用其代理能力，做跨IDC的请求代理，同时也将其和我们的Resin(Java Web 容器)搭配，放在Resin的前面来解决Resin的对网络连接处理能力弱的问题，在一些小地方也用它来做7层的负载均衡

Resin
一个Java Web Server，比Tomcat更高效，是我们主要的Java Web容器

Squid
代理服务器，我们用他来做图片文件的反向代理缓存

LVS
能提供4层的负载均衡，高效、高可用，高并发。我们用他替代了很多硬件的负载均衡设备

Struts
Java web框架，不过这个已经是历史了，我们开发了一套自己的Web框架替代了它，未来我们也会把我们的内部的这套Web框架开源出来

Lucence
基于Java的搜索引擎框架，用它我们构建了一个搜索集群来提供搜人的服务

Netty
一个Java的网络框架，和apache的mina类似，但比mina更高效，我们用来做一些小的服务

Ganglia
一个监控系统，帮组我们了解我们每台Server的资源利用情况

还有些小东西就不列出来了，最后要说的一点就是，对这些开源软件或者系统，我们都非常的了解，或者说知根知底，从API到内部实现原理，甚至到一些源码的细节。

由开源软件组成的系统
与很多大型的网站一样，人人网的系统全部是由开源软件构建的。使用Nginx做前端接入，resin做容器，Memcached做通用cache，MySQL做数据库，使用Linux操作系统。
除了上述的部分外，人人网还有一个与众不同的中间层。中间层以服务的形式存在，位于MySQL和resin中间，提供高并发低成本的数据访问层。

数据库的压力
在上述结构系统中，数据库的性能往往成为系统瓶颈。人人网在发展的过程中不断重构，改变最大的就是数据库部分。大概的步骤是“优化SQL”，“业务拆分”，“垂直拆分”和“水平拆分”几个阶段，关于数据库优化的细节将来再引用到这里。
经过优化后的数据库，单台可以承担每秒3000次的主键查询。再提高性能的优化，我们采用的方案是使用中间层。

性能目标
增加中间层可以在不增加服务器数量的前提下，提高服务的整体性能，并且提高系统的可扩展性。这里简要列举一些使用中间层服务优化的效果。

实时更新的数据

用户的个人信息数据，目前的写操作500次/秒，读操作2万次/秒。这些数据分布在数十个数据表中，如果用数据库做10次主键查询，需要的时间将会非常可观。中间层的缓存服务把这个性能稳定在了99.9%的请求时间小于20ms。
判断好友关系，读操作900次/秒。这个操作现在使用6G内存存储了所有的好友关系，在2ms内返回任意两人的好友关系。
关联查询，仅好友列表就有1300次/秒。如果使用关联查询，数据库需要同步很多无用的字段。现在只需要两次内存请求，并且衍生出很多种类的排序。

大量聚合的访问

聚合的页面在SNS中是访问量最大的部分。首页集成的功能多达17个模块，这些模块之间的关系相对独立。为了快速的把这些数据集合在一起，就需要迅速获取数据。
我们对整体技术框架的要求是，关键页面执行时间要在100ms以内。

Session同步

众多的resin服务器之间，如何共享用户身份验证的结果，在各种session共享机制中，我们的方案是使用中间层服务来集中存储的。

书接上文，为了提高性能，在人人网的技术结构中，在数据库和页面之间，有中间层。中间层高性能的基础是用内存代替磁盘。

用内存代替磁盘
数据库系统的最大瓶颈在磁盘IO，大量的小数据请求不是磁盘的强项。人人网中间层服务就是利用了内存代替硬盘的方法来提高整体性能。有了这层服务以后，以前的数据库关联查询被提前计算并缓存，需要访问时直接获取。
通用的Memcached缓存方案也有些不足，数据不能自己变化，也不能部分变化。于是人人网选择了自己实现缓存的方式。
在自己实现缓存的过程中，管理内存相对容易，通信协议是比较复杂的部分，我们在这方面选择了开源的Ice通信框架（http://www.zeroc.com）来完成繁琐的工作，至今它都工作的很好。
Ice通信框架在人人网完成了两件事，通信和定位。客户端通过IceGrid组件定位到需要的服务地址，将请求发送到中间层服务，中间层服务将结果返回。客户端只需要知道一个地址就可以找到所有的服务；同时，众多服务也可以在不同的服务器之间随意迁移。在现在的人人网有超过500个Ice写成的中间层服务在运行。

定制的内存数据
用Ice解决了通信和部署的问题后，中间层服务就是核心的数据结构管理。概括的说，就是灵活变化，保证速度。下面列举若干使用了中间层服务的情况

一份数据 多种排序

在人人网的好友页，有很多排序方式可以显示好友列表。每种列表都是从一个按ID排序的服务中获取的，再经过排序，缓存在各个顺序的列表中。

随时间变化的数据

在很多列表页面，都会显示“在线标志”，这个标志是冗余在各个列表的缓存当中，定期刷新的。这些需要和cache一起实现的业务逻辑，在人人网中间层当中非常普遍。

特殊类型

我们用了一个bit保存用户的激活状态。200M内存可以保存全部int范围的状态。并且查询和更新速度飞快。
接下来的实践篇将会用这个为例子展示中间层的实现。