日表和小时表）。实时验证一般涉及监控binlog数据库，当数据发生变化时，延迟几秒后请求两个系统的查询接口，找到数据后进行验证。 6、幂等性是针对重复请求的 支付系统一般会面临以下重复请求的场景： 用户重复点击支付按钮：在网络不好或者系统过载的情况下，用户因为不确定是否交易而重复点击已完成。自动重试机制：超时或失败时系统会重试请求，这可能会导致同一笔支付多次尝试。网络数据包重复：在网络传输过程中，数据包被多次复制，导致支付平台收到多个相同的请求。异
常恢复：系统升级或崩溃后，待处
理的事务应回滚并根据现有记 手机号码数据 录完成。内部系统重新提交操作。幂等解决方案所谓业务幂等，是指每个域都以其唯一的事务ID作为数据库中的唯一索引，保证不会出现重复处理。可以在数据库前面加一层缓存来提高性能，但是缓存只是用于查询，它会返回一个幂等成功插入数据库，然后在插入成功后刷新缓存中的数据。为什么要使用唯一的数据库索引作为备份，因为缓存可能会失败？面对这个问题，同学们往往只是回答“使用redis分布式锁实现幂等性”，这是错误的。由于缓存可能会失败，分布式锁只是防止并发操作的一种手段，并不能从根本上解决依赖唯一数据库索引的幂等问题。只要工作是幂等的，大多数简单的支付系统基本上就足够了。 6、分库和
分表 当数据量很大的时候，不可避免的
存在分库和分表。一个经典的面试问题是：如果 品能够低成本的快速 表格被分割，表格应该按交易者分割还是按交易者订单号分割？如果桌子按交易者划分，如何解决平衡各表数据流量的问题？如果表是按交易者的订单号分区的，那么交易者如果想按时间段查询该怎么办？有很多解决方案。典型的解决方案是在线数据库按商户订单号拆分成表，而离线数据库则将冗余数据按商户号分表，甚至直接利用线下数据平台能力按时间段查询商户。在线图书馆。 6.. 分布式事务 分布式事务是个好东西，但是也很复杂，经常会出现所谓的事务中止问题。而且虽然每个公司都声称简单易用，对业务代码的侵入较少，但事实并非如此。所以我个人更喜欢案，而是使
用最终一致性。对于大多数中小型企业来说，最终一致性就足够了。 6.5 金额处 zbn 目录 理规范 缺乏研发经验的团队经常犯以下错误：没有统一定义的货币类别，不同的金额处理和存储系统之间使用 BigDecimal、double、long 等数据类型。定义了统一的货币类，但在编写代码时并没有严格遵循。还有一些代码使用BigDecimal、double、long等数据类型来处理金额。手动加、减、乘、除金额并转换单位（元和分）。其后果通常是资金损失。具体来说，最常见的情况如下： 手动转换单位导致金额增加或减少 。例如，每个人都指定信息应该以元来传达，但其中一个学生忘记了，并认为信息应该以点来传达。或者反之亦然。在第二种
