《回忆录》 记录一点经验。高并发，高可靠性分布式系统

  这个学期做一个电信增值的项目，《短信网关》。

  按道理说，这样一个项目，业务层不算很复杂，整个项目难度不大的。但是商家要求是一天400万条短信和不许当机。高并发和高可靠是整个项目的质量指标。

  回忆着大二第二学期所学到的一切,回想那段时间，很辛苦但是很充实，和你们一起奋斗很开心  

------------------------------------------------------------------------------------

  初步设计，oracle集群，程序由调度机和发送机组成。---失败

原因： 1、oracle集群在千兆环境下工作，性能不如单台机。因为oracle集群是中心负责数据，集群点负责运算，SARS 硬盘的I/O 比网口还高，所以千兆口集群不可行。

       2、调度机，发送机这样的设计不符合高可靠性，调度机负责用户的请求，负责调度底下发送机发送短信。用户请求高峰时候，调度机成为瓶颈和依赖。

------------------------------------------------------------------------------------

  第二版设计： nginx +tomcat集群。分布式程序，数据库采用redis集群。

硬件配置：  手头上有很多个学校给的ip，3台8g配置的G6服务器，还有一台忘记什么型号，就知道它有32G内存。

做法： 

    1、如何充分利用完这些资源呢？我们采用了虚拟化技术。利用proxmox EX进行虚拟化平台的集群，上面分别跑2G内存的小机器，这样算下来我们有了十几台服务器了。（新开博客不能上传图片，有机会再贴上proxmox的管理界面），压力测试中，4台虚拟机器。一个做nginx进行负载均衡。3台虚拟机上分别做tomcat集群和redis集群。一天发了430万条短信，未见异常。更加坚定了采用虚拟化技术。

    2、其实采用redis之前，我们曾用memcached+oracle。发现memcached不适合，原因两个：一、memcached提供的功能不能满足我们，我们要在上面封装多一层，来满足我们业务需要。二、我们采用xmemcached这个客户端，是知名的memcached java 客户端，采用nio连接。在压力测试中，速度很慢很慢。采用loadRunner分析一下函数调用周期，发现xmemcached里面的动作是单线程的，所有请求都有一个wait。所以导致在高并发下非常慢。经过决定，采用了redis数据库。它的功能非常强大。详细看redis七种武器。对于redis的并非处理能力，我们产生过2w个连接，单机无压力。后来我们就采用了redis集群。

    3、公司需要人工审核短信，首先想到是Ajax刷新去读出短信内容，感觉这样办法很笨。后来采用了dwr推送技术，后台通过aop切面，把短信内容取出通过dwr推送出web界面。

    4、提供了axis和axis2实现的webservice接口，http接口。压力测试中，axis和axis2的速度差不多。

    5、对于灾难的应对，nginx和redis切换掉死掉的集群点，毫无压力啊。

-----------------------------------------------------------------------------------

总结了一下，学了什么，spring，memcached，redis，nginx+tomcat，dwr，axis，axis2，mybatis,proxmox虚拟化。还有是框架设计（呵呵，可能在大牛眼里这样框架不怎么样，等我能上传图片了，就贴出来讨论讨论）。

这是我java的旅程，一个商业应用的，高并发，高可靠的分布式系统。ps：电信增值业务算不算电信级项目~

大三了，剩下的路，我应该会走向Erlang的世界。