支付系统尚存在的缺陷

1.可靠消息存储方式由mysql改为redis后，存在数据丢失的风险。redis的主从复制为异步复制，若master已经写入了数据，但该数据还未同步到slave上，此时master发生崩溃或断电等情况，可能会丢失部分消息数据，那么若是这些消息正好在消息队列中丢失了，就会存再消息完全丢失的情况。为应对此情况，需要重新设计可靠消息子系统，至少应该为此情况提供一个补偿方案。

2.现有的支付请求都是平均分配到所有账户上的，也就是说系统还不能支持高频账户的业务。该问题的解决方案基本就是以下两种：一，为一个高频账户提供多个子账户，每次账户增减产生的历史记录中仍旧有账户余额一栏的显示，即仍旧采用行级锁，只是粒度变小了，同时建议加款操作统一在子账户中完成，二类似退款的操作在父账户中执行，需要一个定时任务，周期性的将子账户的钱汇总到总账户，但此设计也会存在一定问题，例如在汇总前会存在该商家的所有账户余额大于退款数目，但是父账户余额小于退款账户的情况，需要等下一次汇总任务执行或提供点击汇总服务（不推荐）。二，放弃为每条账户记录提供当前账户余额字段（目前支付宝应该是采用的此种设计），该设计将不再需要行级锁，因此并发性能大大提高，热点商家的加款性能理论上来说会存在一个质的飞越，缺点是一旦账户出现资金不匹配的问题，追踪难度将大幅提高，同时也要求在编写业务时具有更高的水平。

3.系统因为选择了zk+dubbo架构，服务的健康问题就需要自己整合第三方技术或自己实现服务的健康监测，zk的认为健康的服务只是服务于zk之间的链路健康，而并非真正的服务健康，例如部署了user服务的服务器若与数据库之间网络发生故障而与zk之间的网络却依旧畅通，此时该服务已经是不健康的了，但zk却无法感知。