如何能在多个web服务器1个DB的情况下保证数据唯一?公司里做的项目, 打算用多个web服务器, 共同连一个DB,
如何能在多个web服务器1个DB的情况下保证数据唯一?
公司里做的项目, 打算用多个web服务器, 共同连一个DB, 在某个基础表里的数据需要逻辑唯一, 既某对象(attr1="a", attr2="b")在数据库里只能存在一条记录, 由于这个基础表在用户使用中是用户自定义的, 因此有可能a,b2个用户通过web服务器a和web服务器b同时提交对象(attr1="a", attr2="b")...那么在这种情况下如何使DB里面最终只有一条记录?
公司的做法是:
public synchronized A save(A a){ //查找数据库看有没有a if(没有记录){ //锁表 //插入记录 }else{ //返回数据库记录 } }但我觉得这样还是有问题啊, 因为在查数据库完了之后, 有可能另一台服务器正在保存了, 不过他们解释如果另一台服务器如果正在保存, 这边这台锁表不会成功的, 请问一下, 大家遇到这种情况是怎么处理的?
=================================
也许是我没说清楚, 后面有个同学说得对, 说白了就是多服务器下并发插入的问题, 如何能做到并发插入时保证数据唯一
下面是大家的一些方案(排名不分先后
), 看看还有没有其他的方案:
1. 把save交给一台机器处理,然后暴露API给其他机器使用
2. 乐观锁(这个我觉得似乎不能解决并发插入问题啊)
3. 联合主键
4. 唯一索引
5. 直接往数据库里面插数据，加个时间字段，精确到毫秒级就差不多了，取最新的那个时间字段的行
6. 做一个数据库操作锁，方法调用前都要取锁，取到锁的才用执行，否则等待，这个锁可以放在缓存服务器中，集群中的所有节点连上这台缓存服务器
===============================
加说一下: 这个表是有pk的..比如表结构是:A(id pk auto_increment, attr1, attr2, attr3....)
id是数据库自己递增的, 业务要求是:attr1, attr2....任意2条数据不能重复, - -!这样是不是用唯一性索引就能解决了? 30 楼 dmewy 2009-08-10 这么简单的东西搞得这么复杂.
你要说清楚插入什么数据才会出现这种情况.
你把表设计好就行了.
你N太APP SERVER都是只一台DB.
根据你的业务把主键设计好就行了.
为何会出现两个字段肯定相同的情况?
那就说明这两个字段不适合做PK.
你再根据业务类型建立个PK就行了.
这明明就是一个表结构设计的业务问题.
这里非要搞成一个技术贴.
不懂不懂.
连锁都搞出来了.. 31 楼 gloomyd 2009-08-10 这个可以在设计上加于考虑
如果这个记录只有主键约束，则可以考虑主键在插入的时候生成，或者是使用sequence。
如果有其他的约束，可以先锁住该记录，比如oracle的select **** for update
然后再去插入或者更新操作。
32 楼 pipilu 2009-08-10 你那是跨进程的东西，加上sychronized有用么？服务器A上的实例跟服务器B上的实例互斥？ 33 楼 by5739 2009-08-10 pipilu 写道你那是跨进程的东西，加上sychronized有用么？服务器A上的实例跟服务器B上的实例互斥？
不是, 那个是防止2个用户在同一台web服务器新增同样的数据用的 34 楼 wxjiaaa 2009-08-10 比较支持弄个专门服务器专门处理数据库事务，其它服务器直接调用它的增删改查的接口来进行操作。对于单机操作的话应该就不会出现楼主所担心的顾虑。 35 楼 pipilu 2009-08-10 by5739 写道pipilu 写道你那是跨进程的东西，加上sychronized有用么？服务器A上的实例跟服务器B上的实例互斥？
不是, 那个是防止2个用户在同一台web服务器新增同样的数据用的
那这就不只跟多个Web应用服务器有关系了，最好能从业务上避免这种提交。 36 楼 treblesoftware 2009-08-10 zelsa 写道把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子，是不是有些浪费了，而且SAVA请求过多，是不是会网络堵塞，有更好的解决方案吗。 37 楼 lixjluck 2009-08-10 treblesoftware 写道zelsa 写道把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子，是不是有些浪费了，而且SAVA请求过多，是不是会网络堵塞，有更好的解决方案吗。
交给一台机器也有并发的问题吧
是否考虑使用MQ的queue，所有的web发送到mq上，有一个消费者消费这些数据
这种方式有几个问题：
1、异步，不知业务允许
2、消费稍微有些慢
ps. 为什么是会员设置的数据，但是这个表有不和userId有关联。 38 楼 nwangwei 2009-08-10 1.针对这两个字段做唯一索引；
2.然后web服务器上直接插入，抓特定的Exception判断是不是违反了唯一性。 39 楼 airport 2009-08-11 楼主没有把需求说的太清楚，从楼主的意思来看，只有唯一存放的APP逻辑才好解决。
否则你这种复杂判断唯一性的情况，靠数据库解决不了的。 40 楼 by5739 2009-08-11 nwangwei 写道1.针对这两个字段做唯一索引；
2.然后web服务器上直接插入，抓特定的Exception判断是不是违反了唯一性。
这个...我看行...
41 楼 by5739 2009-08-11 lixjluck 写道treblesoftware 写道zelsa 写道把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子，是不是有些浪费了，而且SAVA请求过多，是不是会网络堵塞，有更好的解决方案吗。
交给一台机器也有并发的问题吧
是否考虑使用MQ的queue，所有的web发送到mq上，有一个消费者消费这些数据
这种方式有几个问题：
1、异步，不知业务允许
2、消费稍微有些慢
ps. 为什么是会员设置的数据，但是这个表有不和userId有关联。
这个是基础业务数据, 是使用者自己录入然后在上面做业务的, 是大家共享的基础数据, 所以不和userid挂钩 42 楼 jamiesun 2009-08-11 by5739 写道lixjluck 写道treblesoftware 写道zelsa 写道把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子，是不是有些浪费了，而且SAVA请求过多，是不是会网络堵塞，有更好的解决方案吗。
交给一台机器也有并发的问题吧
是否考虑使用MQ的queue，所有的web发送到mq上，有一个消费者消费这些数据
这种方式有几个问题：
1、异步，不知业务允许
2、消费稍微有些慢
ps. 为什么是会员设置的数据，但是这个表有不和userId有关联。
这个是基础业务数据, 是使用者自己录入然后在上面做业务的, 是大家共享的基础数据, 所以不和userid挂钩
有什么浪费的，这样的系统本来就该用这种模式。如果save的压力过大，异步MQ是应该考虑的，数据库的能力终究是有瓶颈的，用一个集中的AppServer来处理具有更好的系统伸缩性。
43 楼 manyinjin 2009-08-17 乐观锁可以解决这个问题。还有另外一种思路，就是在app server之间共享一个锁，设置一个对所有app server起作用的写锁,这个需要用一些工具，如terracotta。这样的好处是你可以不用考虑你的app 最终部署到多少台机器上，需要部署多个实例时，只需要通过简单的配置就可以保证多server并发读写的正确性。 44 楼 cs_sehu 2009-08-17 其实你们公司的做法就可以解决你提出的问题了....
在保存之前就已经查询了表里有没有相同的记录....
就算2台web服务器同时提交,在DB操作save方法的时候都会有先后顺序,
后一个save操作的时候查询的时候就有了相同的记录...就不会在save
不必要想的那么复杂. 45 楼 erikchang 2009-08-17 不就是一个简单的分布式嘛！save等操作放到统一服务器上，其他的调用就是你，哪有那么复杂的啊！ 46 楼 liujickson 2009-08-18 很简单的告诉楼主，使用集群式（负载均衡）就完全不用考虑上述情况了。建议楼主多看点构架方面的书籍... 47 楼 aacc321 2009-08-18 对，这是一个集群问题，数据软件架构要解决的问题，我认为最好方案是ejb 48 楼 jameswxx 2009-08-18 这个是属于典型的数据库封锁和并行性的问题。
你们这个在应用上解决的方案，从这可以看出你们这个团队没有人懂数据库。
如果你不想深入研究数据库锁知识，你可以看看的hibernate的锁机制。会对你有帮助。 49 楼 by5739 2009-08-19 对的, 我现在只会1web服务器1db的情况, 我很想学构架方面, 但是没找到合适的书籍, 上面兄弟有没有好的架构方面的书籍推荐? 不胜感激.....
), 看看还有没有其他的方案: