路在何方

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系统实施，实施细节随着下一步调查的深入会逐步展开。

未完待续......