今天以交易所订单系统为参考，聊一聊Redis使用场景，交易系统的订单系统与电商订单系统不同，如下图：
系统对比
数据库是支持事务的关系型数据库，数据需要写入磁盘，读写效率比较低，大流量透传到数据库，数据库连接数用完负载过高而宕机，或者数据库连接池连接数用完，导致大量用户查询、提交订单失败或者等待超时，我们使用缓存来缓解数据库读压力，订单数据存储类型有List、Map我们选Redis缓存组件，Redis支持复杂数据类型数据的操作，MemoryCache只支持kv的基础类型。
我们怎么写缓存，先写缓存还是先写库，怎么保证缓存数据和数据库数据的一致性，分布式系统里选择哪一种策略都会有数据一致性问题，我们如何选择策略和解决数据一致性问题，策略总结如下：
缓存策略
交易系统订单系统属于写多读多的场景，同时对数据准确性要求高，数据可以延迟不要错误，订单缓存策略选择做个分析。
如果采用先更新缓存再写库，写库失败时，写缓存和写库间隙期的查询是脏数据，除非有机制能保证数据库一定写入成功，比如：写库失败可以重试，重试失败，把写库的动作push进入消息队列，消费端去写库，直到写成功了再删除。
如果选择先写库再删除缓存，或者先删缓存再写库，这个场景下，会频繁的读库和写缓存，而且还有数据库主从同步问题，小团队也没有精力去实现binlog订阅更新缓存机制。
我们选择先写库再更新缓存策略，数据库事务机制解决了多个写库并发一致性问题，主从同步延迟只会延迟最新结果显示。
