这两篇文章涉及的券商业务系统，主要包含交易系统和业务支持两类。交易系统主要有两类任务，一是满足客户的日间交易，是典型OLTP；二是完成盘后 的清算，类似于银行的结算批任务。而业务支持类主要注重数据挖掘与分析，是典型的OLAP。
文中所述痛点还是比较切合实际的，针对其推导出来的用户需求我分别说一下，欢迎参与讨论交流：
1、高弹性。中国是典型的散户市场，日间交易业务的峰谷差距巨大这个是中国证券行业的现实情况，也是监管的要求。目前来看没有什么好的解决方案， 券商一般是按照满足峰值需求来部署软硬件，行情低迷时则资源大量闲置。按使用计费的云可能是一个解决思路。
2、清算速度。清算是重IO负载的批任务，在业务逻辑、SQL及数据库性能已调优的情况下，全闪存应该是不错的解决方案。不知道国内金融行业有没 有成功的案例可供参考？
3、高并发。各券商的部署不尽相同，从我司的情况看，达到高并发的瓶颈一般不涉及存储IO，更多的可能在业务逻辑、业务通道能力、网络能力等方 面。
4、同城异地容灾。券商的日间交易业务本质上是一种通道服务，因此在容灾切换时，首要目标是恢复服务，允许少量事务丢失。文章中提出的存储层数据 同步，和券商很多采用的业务数据逻辑同步（数据同步软件）相比，各自的优势和劣势是什么？
收起