路在何方

FX系统经过了四年的发展，一直以利用开源技术为主线。随着系统访问量的激增，交易量的不断加大，数据库作为瓶颈的矛盾越来越明显，是时候动手术了，呵呵。


本周调查了如下的技术：
* GAE
* NoSQL
* Mysql + HandlerSocket
* MySql + MemCache
* Mysql NDB Cluster 7.1

结合目前FX系统来说，上述技术各有优缺点：
1、GAE
   该技术如果应用在FX系统中，可以降低客户的投入，客户不用在硬件设备
   以及运营维护上投入任何费用；而且对于利用GAE的开发公司来说，比如
   EAT，在开发设备、测试设备上的投入也将为零，所以应该是一件非常好的
   事情。
   但是目前GAE的发展还不是很成熟，存在以下限制：
   * 数据库方面
     因为FX是金融系统，金融系统的数据库安全性的要求比较高，所以如果
     使用GAE的话，希望APP GAE化，而数据库为private，但是目前GAE对这
     个暂时还不支持；
   * 对后台进程的支持较差，基本上只能运行30S的时间，这对FX系统来说是
     完全不适用的；
   * 存储空间
   * 带宽和流量
   * 响应时间
   * SQL限制
   * 线程限制
     目前还不能使用线程
    由于上述限制，FX系统的迁移将非常困难。

2、NoSQL
   由于数据结构本身和RDBMS有很大差别，所以如果在FX系统中利用此项技术的
   话，整个系统需要结合Nosql的数据结构全部重新设计。
  
3、MySQL + HandlerSocket
   * CLient API的限制
     目前HandlerSocket 只提供了C++和Perl的Client API，所以现有系统利用
     HandlerSocket 需要假以时日；也可以通过Java调用C++或者Perl API的方
     式，但是担心跨语言访问会有问题；
    
   * 查询限制
     HandlerSocket 只是对于Primary Key的查询性能大幅提升，所以客户端代码
     需要有针对性地进行调整。
    
   * Memory的限制
     所有数据都需要在内存中存放。
   * Security
     HandlerSocket's worker threads run with system user privileges, so
     applications can access to all tables through HandlerSocket protocols.

     现有FX系统的主要问题是系统容量的问题，即Mysql5.1的TPS为1800，现状支持
     10000人应该没问题，但是随着online人数以及系统交易量的增加，瓶颈问题会
     更加突出。而HandlerSocket只是提高查询性能，所以虽然可以考虑在系统关键
     模块比如MarginCut等使用，但是仍然需要寻求提升系统容量的办法；
   
4、MySql + MemCached
   在许多大型网站都应用此种架构，所以架构本身没有问题。而且MemCached本身确实
   分担数据库的负载，如果把FX系统的Alive数据全部放入MemCached中，那么数据库
   的压力可以被分担掉70%。
  
5、Mysql NDB Cluster 7.1
   Mysql NDB Cluster 7.0  4Node目前的TPM可以达到250000，是现有FX系统的2倍，
   可以考虑现有FX系统中利用NDB Cluster。
  
   近期想进行Mysql NDB Cluster 7.1 4Node的TPM测试，根据测试结果决定下一步是否
   利用。
  
  
综上，3、4、5可以考虑在FX系统实施，实施细节随着下一步调查的深入会逐步展开。
  
未完待续......