我正在开发一个项目，我们收集有关帐户的(last_x，计数器)信息。 用户操作可能会导致生成多个业务事件。当网络上的单个用户操作导致多个事件时，它将触发对 USER HISTORY 表的更新。
我们使用乐观锁定来确保所有事件都会导致 USER HISTORY 表的更新。
问题:
乐观锁定会导致额外的读取(当检测到冲突时，再次读取并更新)和额外的写入(解决冲突后)。
尝试的解决方案:
- 每个事件都会插入到 USER HISTORY 表中 - 历史信息过多，导致读取性能较差。
还有其他选择吗？
最佳答案
是否有压倒一切的需要在此表上实现读取性能？
在我看来，这是某种“工作日结束”/每小时左右的客户资料/情报表。如果是这种情况，那么您可以只使用插入并考虑数据仓库技术，例如 Star Schema照顾事物的(last_x，计数器)方面。
如果它更关键并且依赖于时间，那么您的架构可能不适合这项工作。您是否考虑过使用消息中间件，例如 JMS通知并触发其他业务事件？
由于您使用 Oracle，您可以查看:Oracle AS
[编辑]根据讨论，您有一个计数器信息的实时生产者/消费者。我不认为数据库是解决这个问题的基本方法。您可能需要保留计数器用于会计目的，所以也许您需要这样的东西:
生产者:init(从数据库重建 session /memcached)
RECV 用户操作 X -> session /Memcached(ActionX) + 插入数据库。
消费者:正在运行(检查 session /memcached 的条件、操作)
您甚至可以使用户历史记录计数器的使用者成为生产者在计数器达到 X 时触发的事件的订阅者，并消除使用者对 USER HISTORY 的依赖
关于java - 是否有乐观锁的替代方案，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9832135/