某证券清算系统的一次性能调优

1.     场景

上线前，用户预估平均一天交易量约一万条，峰值约两万条。项目上线第一天，交易量有4万条。对于这4万条左右的交易信息的清算，花了一个多小时（清算时需要我们系统发指令给清算所，由清算所按照我们系统的指令进行清算，最后把结果通过MQ返回给我们）。用户提出以后交易的峰值可能达到一天5万条。

2.     任务

我们按照2倍的处理能力，定下一天10万条交易信息的处理量的目标。按照一条交易信息对应3个MQ消息计算，在清算窗口内（5点半开始到8点半关闭），需要处理30万个消息，平均每小时10万。同时观察到处理性能随着时间是线性逐步下降的。

3.     行动

系统主要涉及异步MQ通信(SSL和AMS双重加密)，JVM处理，数据读取以及数据存储等方面，性能优化从这几个方面入手。

A.    数据存储方面 – 提升25%

a.     考虑到清算后是T+3交割，因此系统只要保存4天内的数据即可（热数据）。如果用户有查询需求，可以从归档表（冷数据表）进行查询。超过1年的数据则可以归集到离线数据库。这样处理后，由于热数据总量基本是恒定的，而且减小了数据总量，读数据的性能提高了20%左右，也不会随时间下降。

b.     经过研究，sybase针对主键会有clustered index，由于主键不是递增的，因此新的数据插入可能会导致数据存储物理顺序重排，因此把primary key改成unique key。此项修改系统性能约提升了5%。

B.     JVM代码方面 – 提升30%

a.     系统从MQ收到消息后，是先落数据库，然后马上确认消息被消费掉。同时这里还会把每个消息以文件的形式写到NFS上。考虑到数据库和MQ在同一个事物里面，不需要担心数据的丢失，这里对“消息以文件的形式写到NFS”这个操作放到另外一个线程池里做异步化处理。系统性能提升约10%。

b.     每条消息被java代码处理后，原先系统会记录系统的操作日志（什么时候，处理了什么消息，处理结果是什么）。考虑到性能问题，以及这里是单个JVM，不涉及分布式，这个系统日志也做异步化处理。如果记录日志出错，则马上邮件通知运维组的同事马上处理。这里的关键是，只要系统的关键业务处理都正常，则系统的结果就是正确的，操作日志不应该影响这个业务的处理结果。系统性能提升约15%。

c.     清算所的消息的大小有明确上限，因此每个消息能承载的交易信息条数有上限。原先的上限设的比较小。我重新计算每条交易信息的字节数，再重新计算出每个消息能承载的交易信息的上限，把个数从1000调整到了1800。这个调整系统性能上升约5%。

C.    数据读取方面 – 提升100%

a.     针对每条SQL语句，我们找DBA帮忙分析，看是否hit到正确的索引上面。同时每天晚上系统停止运行后，都去重建索引，更新统计数据，确保索引会正常工作。

b.     优化SQL语句，例如有的select * from table A, table B，改成 select columnA, column from A inner join B on A.key=B.key。显式使用正确的join，效率会比fromA,B要好。

c.     减少数据库读取次数。原先的设计者可能考虑到数据量比较大，担心内存不够，因此所有待处理的消息不是全部一次性读取到内存里面。后来我经过测试，每条消息上限最大10K，按照最多30万条消息（实际上消息是分阶段过来的，不会一下子30万全部过来），总的内存占用不会超过3G，因此完全可以一次性把全部待处理消息全部读取进来，处理完后再处理下一批。

4.     结果  

经过不断优化后再测试，每小时可以处理12万个消息，可以满足用户需求。主要感触是要有主人翁精神，本着用户至上的精神，要想尽办法满足业务的需求，给客户‘如沐春风’的感觉。在技术上，要知其然并知其所以然，理解背后的原理，灵活运用到项目上。只有对业务有深入的理解， 在技术上大胆假设，小心求证，才能让技术更好的为业务服务。