一个关于数据库并发压力转化到tomcat并发的讨论

Question

数据库并发设计mysql服务器

Answer 1

连接池是c3p0,测试的时候发现的确是 sql理论上执行成功了时候返回1，但是有的请求超过等待时间就返回的0了

Answer 2

思路是错的，越是底层的压力越是不好分担，tomcat所在的服务器离开了数据库以后连剩余资源的数量都不知道，如果响应用户的请求？可以考虑从业务上改造你的流程：可以参考小米/12306的排队策略
预先构造好有权限更新的队列（小米和12306的排队），tomcat只放100个人进来，其他的人直接提示更新失败，然后在慢慢的处理这100个更新的请求，这样数据库的压力就小了

Answer 3

有个小想法，楼主看能参考下不 类似于 冰糕数的这种数据，能不能在服务器本地做一个缓存，然后在缓存中进行计算，这样计算的压力就在服务器侧了
固定一个时间把当前的结果提交到数据库进行记录，像其他字段，比如账户余额，因为是1对1，所以可以继续在数据库中直接操作 当然既然是跟票子有关系的，自然要保证事务的一致性，不能缓存中操作了，但是数据库中没有操作另外一种可能是从数据库表结构上解决问题，不对单一字段进行修改， 可以新建一张Sales表，记录冰糕的售卖信息，冰糕的总量是固定的

Answer 4

这样的话对于一个在线售卖网站，不太合适吧，像淘宝的一个item 库存跟这个case 有点像，也没有说，我只能多少多少用户进来不知道你看我说的对不

Answer 5

单Tomcat到是比较好实现.
只要把雪糕的数量管理弄到Java类中并建立相应的工厂方法即可.
使用的时候通过过长请求一个雪糕,如果返回了则可以继续执行,没返回则说明没有雪糕了,这是需要提示用户已经售罄了.
得到雪糕的如果执行没有错误则在执行完成后调用工厂的消耗雪糕的方法,否则调用退货方法.

Answer 6

这样的话对于一个在线售卖网站，不太合适吧，像淘宝的一个item 库存跟这个case 有点像，也没有说，我只能多少多少用户进来不知道你看我说的对不
我提到的是一般“秒杀”业务的处理方法，是LZ问题的放大版本，LZ那个问题的关键不在于判断存量，而在于大量的更新请求会直接把数据库拖垮。一般的业务场景下，用数据库硬抗就行了，没必要考虑太多

Answer 7

应该避免update同一条记录，避免产生X锁。
建议：每购买一个雪糕就Insert一条记录，根据count到的结果即已卖出的数量与雪糕总数进行比较，这样不会产生X锁。

Answer 8

你的数据库有没有多个Server并发访问？
如果没有，那么程序启动的时候把数量读到从数据库读到内存，直接操作内存就好了。