稍微有一些项目经验之后，如果再深入下去，可能会接触到高并发、分布式，相关的工具集和技术有：并发编程、分布式事务、Redis、数据库集群、消息队列、Hadoop、微服务……总之你能张嘴喷出来的高大上的词汇越多，就越显得你厉害，足以让新手自卑，让外行赞叹。
我差点就走上这条不归路。无数次的事实已经证明：没有最好的技术，只有最合适的技术。如果脱离实际场景去照抄别人的解决方案，结果只能是东施效颦。我听过不少人高呼：解决分布式问题，一定要用分布式事务。你要是给他个赞许的目光，他一会儿就能接着侃侃而谈：CAP理论、柔性事务……说了个把钟头，他甚至都没关心具体的业务是什么。
我们假设这样一种场景：系统A和上游系统保持TCP长连接，上游不断地给A发送消息，而A要对每条消息做到尽快地处理，上游发送消息的频率是相当高的：超过100MPS(message per second)。系统A用了队列缓存接收到的消息，然后从队列中不断取出消息进行处理。处理结果要持久化，然后通知下游系统。这样的场景下，使用关系数据库必然是致命的。用消息队列呢，很遗憾传统的mq也不能满足要求，mq并不能加快一个事务的处理速度，说白了，mq就是个远程的队列，最大的作用就是缓冲压力，也就是所谓的削峰填谷，和实时处理完全就是相悖的。
那么Redis能解决我们的问题吗？并不能。我已经不止一次见到有人拿Redis当“比较快的数据库”来用，直接进行处理结果写入，写到redis就想当然的认为业务处理成功了，真是勇气可嘉。回到系统A，快速的处理一个事务并进行持久化的关键在于两点：
1、让事务尽可能简单
2、采用追加写入的方式进行持久化，比如LevelDb（微秒级写速度）、或者自己用相关的文件操作类也可以
第2点很简单，那如何让事务的处理尽可能简单呢？传统的事务处理就是因为过多的磁盘读写操作拖了后腿。到这里解决办法已经很清晰了：我们只记录动作，不记录数据。毕竟有了所有的动作，就有了所有的数据，mysql的binlog差不多就是这么个思路。缓存解决了读的问题，db操作不过就剩下：增加、删除、编辑这三类写操作，如果我们不直接操作数据，而是只记录类似“增加了数据A”，“删除了数据B”这样的动作（我们又称之为事件），那么依据这些事件，我们就可以从0重演出整个系统的状态。
针对系统A的场景，我们最终的解决办法是：
1、全内存运行
2、每次事务只存储事件
带来的好处之一：业务逻辑没有任何db操作，持久化事件完全可以封装在消息入口处，业务Handler纯内存操作，而且由一个线程调度，进而完全避免了多线程并发问题；
带来的好处之二：系统有了重放事件的能力，可以精确还原用户每次操作的数据场景，对重现bug意义重大。
天下没有免费的午餐，就算是西北风，也得自己张嘴去喝。
带来的坏处是：新技术（其实是多年前老掉牙的技术了，对我们团队来说是新的尝试）带来新问题，前期的框架修修补补，因为要做成分布式的，所以主节点和从节点需要事件同步，以保持程序状态的一致，好在这些问题是框架层面的，解决一次就行了。
重申一下：解决任何问题都得看具体场景。如果对实时处理没有苛刻的要求，做好缓存和代码优化，对付一般的应用场景完全足够了，分布式也好、redis也好、mq也罢能不用就不用，不考虑场景硬是尬用各种框架、工具无异于往自己身上滥贴狗皮膏药。
尽量不要用那些看似高大上的技术，任何东西都有成本，面对一个明明用CRUD就足以解决的小系统，要是我们张口闭口就是高并发、分布式，吭哧吭哧把自己累得跟孙子似的的搞出了所谓的分布式架构，一上线，同时在线用户高达3人——你说尴尬不尴尬。