多微服务实例共用PostgreSQL数据库，不依赖数据库时如何保障数据一致性与并发？

当不能依赖关系型数据库的并发控制和一致性机制时，可从服务层、中间件层、业务设计层入手解决，以下是几种实用方案：

一、本地锁+分布式锁双层防护 #

• 先通过本地内存锁（如Java ReentrantLock、Python threading.Lock）拦截同一实例内的线程并发，减少跨实例的冲突概率，降低分布式锁的压力。
• 跨实例的并发用分布式锁兜底，基于Redis、ZooKeeper实现：比如用Redis的SET key value NX EX 30命令抢占锁，拿到锁的实例才能执行数据操作，操作完成后主动释放锁。
• 注意事项：必须给锁设置合理的过期时间，避免实例宕机导致锁永久占用；长耗时操作要做锁续期（比如Redisson的可重入锁自带续期机制）。

二、消息队列串行化请求 #

• 将所有数据更新请求发送到消息队列（如Kafka、RabbitMQ），把同一业务标识（如订单ID、用户ID）的请求路由到同一个队列/分区，保证同一数据的操作按顺序执行。
• 服务实例作为消费者从队列取请求处理，天然避免并发冲突——同一数据的操作不会被多个实例同时处理。
• 必须处理消息幂等：给每个消息生成唯一ID，处理前先检查该ID是否已被处理过，防止重复消费导致数据异常。

三、业务层乐观锁控制 #

• 在业务数据中维护版本号或时间戳字段，自行实现乐观锁逻辑，不依赖数据库的WHERE条件校验：

  public boolean updateOrder(Long orderId, BigDecimal newAmount) {
      while (true) {
          Order currentOrder = getOrderById(orderId);
          Long currentVersion = currentOrder.getVersion();
          // 自定义更新逻辑，仅当版本匹配时执行
          boolean updateSuccess = customUpdateOrder(orderId, newAmount, currentVersion);
          if (updateSuccess) {
              return true;
          }
          // 版本冲突，短暂重试
          try {
              Thread.sleep(100);
          } catch (InterruptedException e) {
              Thread.currentThread().interrupt();
              return false;
          }
      }
  }
  

• 这里的customUpdateOrder需要在业务层先校验版本是否匹配，再执行数据写入，核心逻辑由服务层控制，而非依赖数据库的并发机制。

四、事件溯源+状态机模式 #

• 放弃直接修改数据的方式，把所有数据变更转化为可追溯的事件（如“用户充值100元”“订单支付完成”），事件只做追加写入，不修改已有数据。
• 数据的当前状态通过重放所有相关事件计算得出，比如用户余额=所有充值事件总和-所有消费事件总和。
• 这种模式下，并发操作的事件可以并行写入，不存在写冲突，最终状态天然一致，适合业务逻辑可通过事件回溯的场景。

五、分片隔离策略 #

• 按照业务ID（如用户ID哈希取模）将数据分片，每个服务实例只负责处理固定分片内的数据。比如用户ID模4后，0号分片由实例A处理，1号分片由实例B处理。
• 同一数据的操作只会落到固定实例，用本地锁就能控制并发，无需跨实例协调。
• 注意：实例扩容缩容时需要重新分片，要提前做好数据迁移和流量切换的预案。

内容的提问来源于stack exchange，提问作者texmelex