蚂蚁变大象：浅谈常规网站是如何从小变大的（二）

【 前一段时间写了关于架构的总结，一共十篇，放在新浪博客上 : http://blog.sina.com.cn/zgwangbo001 ，今天放到csdn上】

       【第四阶段 ： 第一次服务多机化】        当IO性能得到解决以后，我们可能就会面临CPU瓶颈，即程序处理不过来了。那这个时候，最好的方式，就是优化程序。从整体架构和具体业务逻辑上去分析并做优化（可以借助一些性能分析工具，如gprof，xprof等）。根据之前的经验，反射、正则表达式、字符串拼接、内存拷贝等是吃CPU的大户，所以优化上可以重点考虑。通过性能优化，一般可以将性能提升30-40个百分点。

        如果性能优化后，都还不能满足需求，那可以考虑更换更好的服务器。随着时间的推移，硬件发展极为迅速，且成本下降非常明显。可以考虑双核、4核等多核服务器。这样是提升服务性能最快的方式。

        如果这样都还不能满足需求，那么，恭喜你，说明你的网站流量已经有一定规模了。接下来，就是——多机。

        多机是小网站从技术架构上要迈出的第一步，也是一个质的飞跃的阶段（想当年，我还利用JAVA提供的库做了一个可多机的网站，不过一直没用上，哈哈）。这个阶段，最简单的就是将WebServer、数据库和cache这两个东东移动到另外的机器上去，利用WebServer、数据库和cache的网络协议对其进行访问。这样就能将原本被他们占用的cpu给我们的逻辑程序使用。

 

        通过这样的拆分后，我们就迈出了多机的第一步。虽然看起来比较简单和容易，但是这也是非常具有里程碑意义的。这样的优化，可能会提升20－30%左右的一个CPU idle。能够使得我们的网站能够经受更大的压力。

 

――――――――――――― 休息一下的分割线 ―――――――――――――

 

        昨天在济南玩了一天，去了传说中的大明湖畔，虽然没有看到夏雨荷，不过却领略了春意的盎然，各种花争奇斗艳。看了趵突泉，对泉没啥感觉，不过对泉里的鱼到是很深的印象——太肥了。

        另外还吃了一个比较有特点的早餐——甏肉米饭。早上起来吃硕大一块五花肉。现在想起来都觉得有点腻。

        今天去青岛，现在正在高速上。待会儿该我开车了，先上图，必须有图有真像。

 

――――――――――――― 技术继续开始的分割线 ―――――――――――――

        

         【第五阶段 ： 逻辑程序的多机化】

 

        当我们的访问量持续增加的时候，我们承受这成长的快乐和痛苦。流量刷刷往上涨，高兴！但是呢，服务器叫苦不绝，我们的程序已经快到不能服务的边缘了。怎么办？

        “快使用分布式，哼哼哈嘿”J

        这个时候，我们就需要针对CPU瓶颈，将我们的程序分别放在多台服务器上，让他们同时提供服务，将用户请求分摊到多个提供服务的机器。

        好，如果提供这样的服务，我们会遇到什么样的问题？怎么样来解决？

        我们一个个的来分析：

        一、WebServer怎么样来分流用户请求？That’s a good question!

        在考虑这个问题的时候，我们常见的WebServer早已给我们想好了解决方案。现在主流的WebServer几乎都提供一个叫“ Load Balance”的功能，翻译过来就是负载均衡。我们可以在WebServer上配置一组机器列表，当请求来临的时候，WebServer会根据 一定的规则选取某一台机器，将请求转发到对应的逻辑处理程序上。

        有同学马上就会问了，“一定的规则”是怎么样的规则？他能解决什么样的问题？如果机器宕了怎么办？……

        哈哈，这里的一定规则就是“ Load Balance”。负载均衡其实是分布式计算和存储中最基础的算法，他的好坏，直接决定了服务的稳定性。我曾经设计和开发了一个负载均衡算法（现在正在大规模使用），有一次就因为一个很小的case，导致服务大面积出现问题。

        负载均衡要解决的就是，上游程序如何在我们提供的一堆机器列表中，找到合适的机器来提供下游的服务。因此，我们可以将负载均衡分成两个方向来看：第一，根据怎样的规则来选机器；第二，符合规则的机器中，哪些是能提供服务的。对于第一个问题，我们通常使用随机、轮询、一致Hash等算法；对于第二个问题，我们要使用心跳、服务响应判定等方法检测机器的健康状态。关于负载均衡，要谈的话点其实很多，我之前也写过专门的一篇文章来介绍，后续有空了，我再详细的描述。

        总之，分流的问题，我们可以通过负载均衡来比较轻松的解决了。

        

        二、用户的session如何来同步？That’s a good question,TOO!

        虽然HTTP协议是一个无状态的服务协议，但是，用户的基本信息是要求能够保证的。比如：登录信息。原来在单机的时候，我们可以很简单的使用类似setSession(“user”, ”XXX”)的函数来解决。当使用多机的时候，该怎么样来解决呢？

        其实这个问题也是当年困扰我很久的一个问题。如果用setSession，用户在某一台机器上登录了，当下次请求来的时候，到其他机器了，就变成未登录了。Oh，My God！

        Ok，让我们一个个的来看：

        1、一台机器登录，其他机器不知道；

        2、用户请求可能到多台机器。

        对于第一个问题，如果我们在一台机器的登录信息让其他机器知道，不就OK了嘛。或者，大家都在一台机器上登录，不就可以了嘛。    对于第二个问题，如果我们让同一个用户的请求，只落在同一台机器上，不就OK了嘛。因此，我们可以提出三种解决方案：

        1、提供session同步机制；

        2、提供统一session服务；

        3、将同一用户分流到同一机器。

        嗯，这三种方式，你会选哪个呢？如果是我，我就选最后一个。因为我是一个懒虫，我会选最简单的一个，我信奉的一个原则既是：简单粗暴有效！哈哈。在WebServer层使用一致Hash算法，按session_id进行分流（如果WebServer没有提供该功能，可以简单写一个扩展，或者干脆在WebServer后面做一个代理即可）。但是这种方案有一个致命的问题，当一台机器宕机了以后，该机器上的所有用户的session信息即会丢失，即使是做了磁盘备份，也会有一段时间出现session失效。

        好，那看看第一种方案。其实现在有一些框架已经提供了这样的服务机制。比如Tomcat就提供session同步机制。利用自有的协议，将一台机器上的session数据同步到其他的机器上。这样就有一个问题，我需要在所有的机器上配置需要同步的机器，机器的耦合度瞬间就增加了，烦啊！而且，如果session量比较大的话，同步的实效性还是一个问题。

        那再来看看第二种方案，提供统一session服务。这个就是单独再写一个逻辑程序，来管理session，并且以网络服务的方式提供查询和更新。对于这样的一个阶段的服务来讲，显得重了一些。因为，我们如果这样做，又会面临一堆其他的问题，比如：这个服务是否存在单点（一台服务器，如果宕机服务就停止），使用什么样的协议来进行交互等等。这些问题在我们这个阶段都还得不到解决。所以，看起来这个方案也不是很完美。

        好吧，三种方案选其一，如果是你，你会选哪一种呢？或者还有更好的方案？如果我没钱没实力（传说中的“屌丝”，哈哈），我就可能牺牲一下服务的稳定性，采用代价最低的。

 

        三、数据访问同步问题。

        当多个请求同时到达，并且竞争同一资源的时候（比如：秒杀，或是定火车票），我们怎么来解决呢？

        这个时候，因为我们用到了 单机数据库，可以很好的利用数据库的“锁”功能来解决这个问题。一般的数据库都提供事务的功能。事务的级别分多种，比如可重复读、串行化等，根据不同的业务需求，可能会选择不同的事务级别。我们可以在需要竞争的资源上加上锁，用于同步资源的请求。但是，这个东东也不是万能的，锁会极大的影响效率，所以尽量的减少锁的使用，并且已经使用锁的地方尽量的优化，并检查是否可能出现死锁。

        cache也有对应的解决方案，比如延迟删除或者冻结时间等技术，就是让资源在一段时间处于不可读状态，用户直接从数据库查询，这样保证数据的有效性。

 

        好了，上述三个问题，应该涵盖了我们在这个阶段遇到的大部分问题。那么，我们现在可以把整体的架构图画出来看看。