消息推送方案之谈

​ 由于是对接其它平台，接收第三方消息推送细节比较多，如果遇上做活动或者某个时刻并发上来，即使 tomcat 把所有的这些消息请求都放进来，框架内部也可能遇到持久层并发的限制。消息推送虽然也有重发确认机制，但代码总是人写的，一次完整的把所有流程没有问题的运行，还是有概率出现错误。这些问题集中起来，做到一个完整的健壮的系统，还是得想清楚，有一套完整的机制，从设计上减少错误的出现。

​ 收到第三方推送的消息后，通过一步消息推送到另一个地方，统一处理，增加高并发抗峰值的能力，同时，也可以使代码解耦，消息接收、处理是分开的。

​ 推送方案图:

​ 消息处理的过程中，关键的点尽量把日志打出来，打印关键或者所有的变量都可以，推荐尽量重写 Object 的 toString() 方法，不要怕麻烦，到时候上线运行了，出错，日志能让你尽量知道错误现场那一刻的变量，找出bug，而不用猜测各种可能性。

​ 在异步消息的处理过程中，可以的话，考虑设计好错误处理机制，错误了该怎么处理：直接抛出异常、重试机制、通知第三方消息处理失败，多考虑一点，出现问题的概率小一点。

​ 总结了自己想到的和真实项目中遇到的，希望有用。