分布式系统中，JVM是否支持锁或者计数器的概念，或者提供相应的组件？
 |
chainhou
2014-05-17
近几年，各大电商甚至各个运营商，都经常搞一些秒杀活动、抢红包等。比如某月的11号10点，某品牌手机“1元秒杀”，限量100部。
此时，必然在10点前后，网站的并发量会相当大。为了应对网站的高并发，我们可以使用应用服务器集群，负载均衡器会将请求分发到各个应用服务器，这样各个应用服务器的流量就会小很多。但由于集群时同一个应用部署在多个应用服务器上，此时，对于这个100部的限量，该如何保证不会卖多呢？ 单节点的时候，我们可以在应用内部使用锁和计数器来保证，可以使用类似于JDK内部的CountDownLatch这些并发组件，但在集群环境下，这个应用内的计数器就没有意义了。应用被分发到各个服务器，此时为了保证这个数据的正常，一般常用的手段有哪些呢？ 分布式的JVM是否可以使用锁或者计数器的概念？这个在分布式JVM中是否有原生的支持呢？还是有类似于分布式锁的组件？ 
假设我们可以让所有的Server访问同一个数据库，这样来限制，但此时数据库就会成为瓶颈。为了解决瓶颈问题而采用数据库集群的话，各个数据库之间如何保证数据的同步的呢？ 另外，如果使用Redis等分布式缓存，这样的话，为了解决单点问题也必然会有多个分布式缓存存在。此时多个缓存节点间的数据如何保证？ 由于没有从事过互联网上这类产品的开发，不清楚这类实现原理，请R大和组内的朋友们解惑，谢谢！ |
 |
小施_重名后缀
2014-05-18
首先声明我水平比较低,约等于来搞笑.
如果是那种秒杀型的场景.可以做个偷懒. 直接把资源拆分了.比如卖100台,10服务器. 每个服务器各自卖个10台了事. |
 |
ZHH2009
2014-05-19
秒杀之类的话题或许你可以到微博上咨询一个叫 @平民架构 的人，他比较懂。
|
|
chainhou
2014-05-19
ZHH2009 写道 秒杀之类的话题或许你可以到微博上咨询一个叫 @平民架构 的人，他比较懂。
谢谢ZHH。十分感谢！ |
 |
RednaxelaFX
2014-05-20
现实中确实是有“分布式JVM”（Distrubuted JVM）这种东西。它们通常也确实有“共享堆”（shared heap）的概念，还有“远程锁”（remote lock）之类的东西。
另外也有在JVM之上、应用层面之下的解决方案来实现JVM集群（JVM Cluster）的，像是Terracotta的产品。 但楼主想聊的是秒杀的应用场景。至少以我以前在淘宝工作所知道的状况看，淘宝的秒杀并没有使用这么“高端”的东西；用的JVM还是非常普通的、大家都能下载到的Oracle JDK（近一两年换成用自己定制的TaobaoJDK / AliJDK了，但里面并没有JVM Clustering相关的定制）。 更多的是在更上层（从JVM角度看的应用层内）解决的。而且，一定程度的“超卖”也是允许的，如果我没记错的话有事后订正的步骤。前面@ZHH009也说了，这方面可以去微博问问 
|
|
chainhou
2014-05-20
RednaxelaFX 写道 现实中确实是有“分布式JVM”（Distrubuted JVM）这种东西。它们通常也确实有“共享堆”（shared heap）的概念，还有“远程锁”（remote lock）之类的东西。
另外也有在JVM之上、应用层面之下的解决方案来实现JVM集群（JVM Cluster）的，像是Terracotta的产品。 但楼主想聊的是秒杀的应用场景。至少以我以前在淘宝工作所知道的状况看，淘宝的秒杀并没有使用这么“高端”的东西；用的JVM还是非常普通的、大家都能下载到的Oracle JDK（近一两年换成用自己定制的TaobaoJDK / AliJDK了，但里面并没有JVM Clustering相关的定制）。 更多的是在更上层（从JVM角度看的应用层内）解决的。而且，一定程度的“超卖”也是允许的，如果我没记错的话有事后订正的步骤。前面@ZHH009也说了，这方面可以去微博问问 好的，明白了，谢谢R大的回复。 |
|
subchen
2014-05-26
确实我想不需要那么高级的 JVM 来解决问题。
假设秒杀 100 件物品，我们有100台前端负载均衡服务器，假设秒杀当时的并发量达到的 100万，平均下来每台服务器接受1万的用户。 由于秒杀商品有限，我们可以让每台服务器接受前10个用户提交的订单，其他的用户提交订单直接拒绝(不管商品是否还有货)，这样100台机器也就只有 1000 个订单会处理。 然后我们把这 1000 个订单，统一交给一个订单服务器处理，这个订单服务器跑在单一的 JVM 上，就可以实现你要的功能了。 如果秒杀商品数量较多，或者同时需要秒杀非常多的商品，那么最后的单一的订单服务器是不合适的，需要扩展为负载均衡的多服务器(但是如果单一商品的订单交给相同的JVM来处理的话，也可以解决问题) 当然当然，上面提到的数据只是一直假设，一种解决方法的思路，是否试用需要评估一下。 |
|
chainhou
2014-05-26
subchen 写道 确实我想不需要那么高级的 JVM 来解决问题。
假设秒杀 100 件物品，我们有100台前端负载均衡服务器，假设秒杀当时的并发量达到的 100万，平均下来每台服务器接受1万的用户。 由于秒杀商品有限，我们可以让每台服务器接受前10个用户提交的订单，其他的用户提交订单直接拒绝(不管商品是否还有货)，这样100台机器也就只有 1000 个订单会处理。 然后我们把这 1000 个订单，统一交给一个订单服务器处理，这个订单服务器跑在单一的 JVM 上，就可以实现你要的功能了。 如果秒杀商品数量较多，或者同时需要秒杀非常多的商品，那么最后的单一的订单服务器是不合适的，需要扩展为负载均衡的多服务器(但是如果单一商品的订单交给相同的JVM来处理的话，也可以解决问题) 当然当然，上面提到的数据只是一直假设，一种解决方法的思路，是否试用需要评估一下。 谢谢subchen的回复，这块没有什么相关经验。 引用 我们可以让每台服务器接受前10个用户提交的订单，其他的用户提交订单直接拒绝(不管商品是否还有货) 这种方式是直接通过配置Apache/Ngnix就要以实现吗，让允许的请求排除，后面让其直接转发到秒杀失败页面？ |
|
subchen
2014-05-27
chainhou 写道 这种方式是直接通过配置Apache/Ngnix就要以实现吗，让允许的请求排除，后面让其直接转发到秒杀失败页面？
这个我也不清楚是否Apache/Ngnix能实现这样的功能，至少在 App 层面是可以实现的。 |
|
chainhou
2014-05-28
subchen 写道 这个我也不清楚是否Apache/Ngnix能实现这样的功能，至少在 App 层面是可以实现的。 这个APP层面，是应用内包含一个线程池的东西，在请求超过配置的数据之后，就直接拒绝是吧？但这种情况下，如果访问量特别大，单个App是会有问题的，容易挂了。如果使用应用服务器集群的话，这个App内的控制就无法做到精确了吧
|
