这是一个很好的问题与可能会发生的情况，所以在池化时，我们前端有机制进行判断，当CPU超过某一个设定的阀值后，新的请求就不让进来了，从而避免大家都无法访问的情况发生。同时提供警告，加硬件加硬件才是王道。。。...

资源池化来应对你应用的更高并发请求，通过这种伸缩性来解决你的应用请求，这样是有益的客户体验的。但是资源锁无论在你是传统的集群方式下还是资源池化后都一样需要去提前解决的，即使是单机的并发下你也得去解决资源锁的问题为先。...

双11的各种抢购，银行之类的支付系统，这些都是高并发的已经在使用的业务场景。

nova高可用需要考虑的点：API 服务：包括 *-api, neutron-server，glance-registry, nova-novncproxy，keystone，httpd 等。由 HAProxy 提供负载均衡，将请求按照一定的算法转到某个节点上的 API 服务。由  Pacemaker 提供 VIP。内部组件：包括 *-scheduler，nova-conductor，no...

保险产品比较多，一般实时性要求没银行高高，主要涉及一般是数据试算会对系统要求高点，流程控制是要点，风险控制是重中之重

高并发的处理与物理资源相关，它决定最终能够承担多少量，软件架构相辅相成之，各种扩展，灵活部署架构，关键还在于业务层面的运算复杂度，资源的占用情况。

DASHDB 采用的MPP+SHARE NOTHING的架构非常适用于这种集市系统，同时，DASHDB又加入了内存优化和列存储技术，能有效缩短查询的响应时间

对象存储的特点在于访问延迟较高，请求尺寸较大，对象整块读写，qps较低。因此，对象存储情况下，可考虑尽量把对象大小，打散，分散压力与热度。

读写分离，建议oralce rac+adg（或许你可以使用rac+rac_adg），这是不变的架构，其次是数据的缓存，查询结果的key话，在一定程度上减少了二次查询，当然同时也减少了数据库自己缓存的更新

使用dbd::db2和dbi进行db2数据库连接调用方法会有一定几率造成锁等待，最后报错有人遇到过或知道其原因吗