|
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-08-11
nwangwei 写道 1.针对这两个字段做唯一索引；
2.然后web服务器上直接插入，抓特定的Exception判断是不是违反了唯一性。 这个...我看行... |
| 返回顶楼 | |
|
发表时间：2009-08-11
lixjluck 写道 treblesoftware 写道 zelsa 写道 把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子，是不是有些浪费了，而且SAVA请求过多，是不是会网络堵塞，有更好的解决方案吗。 交给一台机器也有并发的问题吧 是否考虑使用MQ的queue，所有的web发送到mq上，有一个消费者消费这些数据 这种方式有几个问题： 1、异步，不知业务允许 2、消费稍微有些慢 ps. 为什么是会员设置的数据，但是这个表有不和userId有关联。 这个是基础业务数据, 是使用者自己录入然后在上面做业务的, 是大家共享的基础数据, 所以不和userid挂钩 |
| 返回顶楼 | |
|
发表时间：2009-08-11
最后修改：2009-08-11
by5739 写道 lixjluck 写道 treblesoftware 写道 zelsa 写道 把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子，是不是有些浪费了，而且SAVA请求过多，是不是会网络堵塞，有更好的解决方案吗。 交给一台机器也有并发的问题吧 是否考虑使用MQ的queue，所有的web发送到mq上，有一个消费者消费这些数据 这种方式有几个问题： 1、异步，不知业务允许 2、消费稍微有些慢 ps. 为什么是会员设置的数据，但是这个表有不和userId有关联。 这个是基础业务数据, 是使用者自己录入然后在上面做业务的, 是大家共享的基础数据, 所以不和userid挂钩 有什么浪费的，这样的系统本来就该用这种模式。如果save的压力过大，异步MQ是应该考虑的，数据库的能力终究是有瓶颈的，用一个集中的AppServer来处理具有更好的系统伸缩性。 |
| 返回顶楼 | |
|
发表时间：2009-08-17
乐观锁可以解决这个问题。还有另外一种思路，就是在app server之间共享一个锁，设置一个对所有app server起作用的写锁,这个需要用一些工具，如terracotta。这样的好处是你可以不用考虑你的app 最终部署到多少台机器上，需要部署多个实例时，只需要通过简单的配置就可以保证多server并发读写的正确性。
|
| 返回顶楼 | |
|
发表时间：2009-08-17
其实你们公司的做法就可以解决你提出的问题了....
在保存之前就已经查询了表里有没有相同的记录.... 就算2台web服务器同时提交,在DB操作save方法的时候都会有先后顺序, 后一个save操作的时候查询的时候就有了相同的记录...就不会在save 不必要想的那么复杂. |
| 返回顶楼 | |
|
发表时间：2009-08-17
不就是一个简单的分布式嘛！save等操作放到统一服务器上，其他的调用就是你，哪有那么复杂的啊！
|
| 返回顶楼 | |
|
发表时间：2009-08-18
很简单的告诉楼主，使用集群式（负载均衡）就完全不用考虑上述情况了。建议楼主多看点构架方面的书籍...
|
| 返回顶楼 | |
|
发表时间：2009-08-18
对，这是一个集群问题，数据软件架构要解决的问题，我认为最好方案是ejb
|
| 返回顶楼 | |
|
发表时间：2009-08-18
这个是属于典型的数据库封锁和并行性的问题。
你们这个在应用上解决的方案，从这可以看出你们这个团队没有人懂数据库。 如果你不想深入研究数据库锁知识，你可以看看的hibernate的锁机制。会对你有帮助。 |
| 返回顶楼 | |
|
发表时间：2009-08-19
最后修改：2009-08-19
对的, 我现在只会1web服务器1db的情况, 我很想学构架方面, 但是没找到合适的书籍, 上面兄弟有没有好的架构方面的书籍推荐? 不胜感激.....
|
| 返回顶楼 | |
