[缓存] - 3.金融交易系统缓存架构设计

1. 交易数据特点

1.1 数据量极大

交易系统的数据量特大，主要来自以下几种类型的数据。

1.1.1 行情

行情是交易系统最为重要的数据，交易就是在不断变化的行情中寻找时机来实现盈利的。海量的行情主要分成两种，一种是tick数据（也叫逐笔行情），例如彭博行情数据，它会将每一笔交易的行情都发布出来，这种数据量巨大，一天就有4亿多条数据；另一种是每隔500ms发布一次行情，这种相对来说数据量少很多，一天大概1亿条左右。再加上各家公司会根据需求对行情进行进一步的加工，如聚合多种行情形成的聚合行情。数据量一天就会达到数十亿条。

对于行情而言，QPS基本保持在3万/s以上，高峰时段（国内交易时间9:00 - 11:30左右，国外交易时间21:.00 - 23:00）的QPS能达到10万/s。

1.1.2 报价

作为做市商，需要根据行情，通过一定的算法（如跟随当前行情报价、根据设定的差值及当前行情报价，根据行情计算曲线，然后报价）对外报价。由于行情实时变动，导致报价的数据量和QPS也特别高。

1.1.3 权限

由于交易系统要求高安全性，因此，权限的控制粒度必须特别细，加上场景的多样性，导致权限数据量也很大。

1.1.4 监控

监控数据主要包括中间件的监控数据，服务实例的内存和CPU监控数据等，数据量和QPS非常高。

1.2 延时要求极低

行情，报价，交易，权限相关的延时必须极低；监控，

1.3 数据质量根据场景差异明显

例如行情，实时行情延时要求在3ms以内；对于历史行情，如果三年内的行情，延时可以在亚秒级别；对于五年内的行情，延时可以在分钟级别；五年以外的行情，可以存档。

对于订单数据，要求绝对不能丢失，延时在5ms以内。

权限数据，要求不能丢失，且延时在3ms以内。

1.4 HotKey和BigKey问题严重

对于热点交易品种，容易造成HotKey问题；权限也跟着容易照成HotKey问题。聚合行情，报价数据容易造成BigKey问题。

2. 数据存储层

根据数据的特点，以及应用对数据质量的不同要求，对数据的存储方式进行分类和冗余。

hadoop hdfs，mysql，cassandra，ignite

3. 缓存中间件选型

由于我们的场景涉及频繁的查询和过滤，redis这种key/value的模式并不适合；再加上二级缓存的要求，如果使用redis，会使得设计变得非常复杂。因此我们选用了ignite，它的高并发和高性能特点并不亚于redis。

4. 多级缓存

本地缓存可以选用ignite，也可以根据过滤条件的需要，选择caffine或者自研框架。

5. 高性能，高并发解决方案

5.1 预加载

对于热点数据，如权限，市场参考数据，利率曲线等进行预加载，防止造成缓存击穿。

5.2 冷热分离

实时行情，历史行情，历史行情再根据年限分别存储。

5.3 按需存储到不同数据存储组件

冗余