高并发下的业务提交策略(转)

出处:http://www.cnblogs.com/bobsoft/p/3622691.html

最近在考虑电商平台高并发下订单处理问题,

总结如下:

1.绝大部份的BS系统最大的性能瓶颈我觉得应该在DATABASE

为什么?因为其它影响因素(网络,存储,WEB服务器......),是可以通过投入比较快速的解决

网络?通过增加带宽解决;存储?通过存储设备或区域存储,即可解决大容量,可靠性问题;

WEB服务器?可以通过四层或七层负 载均衡解决。

2.而DATABASE最大受限在INSERT,也就是业务上所说的“提交”或“保存”

为什么?对于数据的查询,可以通过缓存集群解决。提交或保存,带来的DB是write lock,是排它性;并随着数据量大或并发高,锁的粒度,锁的时长更大,问题更严重。

3.解决之道?

队列也。

HTTPSQS

● 非常简单,基于 HTTP GET/POST 协议。PHP、Java、Perl、Shell、Python、Ruby等支持HTTP协议的编程语言均可调用。   

● 非常快速,入队列、出队列速度超过10000次/秒。   

● 高并发,支持上万的并发连接,C10K不成问题。   

● 支持多队列。   

● 单个队列支持的最大队列数量高达10亿条。   

● 低内存消耗,存储几十GB的数据只需不到100MB的物理内存缓冲区。   

● 可以在不停止服务的情况下便捷地修改单个队列的最大队列数量。   

● 可以实时查看队列状态(入队列位置、出队列位置、未读队列数量、最大队列数量)。   

● 可以查看指定队列ID(队列点)的内容,包括未出、已出的队列内容。   

● 查看队列内容时,支持多字符集编码。 配置使用如下 一、前期准备 依赖包  http://httpsqs.googlecode.com/files/libevent-2.0.12-stable.tar.gz  http://httpsqs.googlecode.com/files/tokyocabinet-1.4.47.tar.gz  http://httpsqs.googlecode.com/files/httpsqs-1.7.tar.gz
二、安装配置 tar zxvf libevent-2.0.12-stable.tar.gz cd libevent-2.0.12-stable/ ./configure --prefix=/usr/local/libevent-2.0.12-stable/ make make install

tar zxvf tokyocabinet-1.4.47.tar.gz cd tokyocabinet-1.4.47/ ./configure --prefix=/usr/local/tokyocabinet-1.4.47/ #注:在32位Linux操作系统上编译Tokyo cabinet,请使用./configure --enable-off64代替./configure,可以使数据库文件突破2GB的限制。 #./configure --enable-off64 --prefix=/usr/local/tokyocabinet-1.4.47/ make make install

tar zxvf httpsqs-1.7.tar.gz cd httpsqs-1.7/ make make install

说明成功!
三、使用及帮助文档 启动: httpsqs -d -p 1218 -x /data0/queue https://code.google.com/p/httpsqs/

时间: 2024-10-10 04:40:04

高并发下的业务提交策略(转)的相关文章

分布式高并发下全局ID生成策略

数据在分片时,典型的是分库分表,就有一个全局ID生成的问题.单纯的生成全局ID并不是什么难题,但是生成的ID通常要满足分片的一些要求:   1 不能有单点故障.   2 以时间为序,或者ID里包含时间.这样一是可以少一个索引,二是冷热数据容易分离.   3 可以控制ShardingId.比如某一个用户的文章要放在同一个分片内,这样查询效率高,修改也容易.   4 不要太长,最好64bit.使用long比较好操作,如果是96bit,那就要各种移位相当的不方便,还有可能有些组件不能支持这么大的ID.

高并发下linux系统、业务结构性能优化——index(不断更新)

工作中零零散散写了些博客,总结了些知识,当然是从运维的角度.东西一多就乱,闲时突发奇想,这些东西能不能打在一个点上,如果能有一个东西把所有内容串起来并且有一个主题岂不妙哉,也方便查阅和阅读,就像一个网站有了内容后需要一个index主页一样,哈哈,然后就有了这篇置顶博文. 对于主题,我喜欢研究业务架构和大并发相关知识,就定为"高并发下linux系统.业务结构性能优化"了,现有目录结构是根据工作经验进行的梳理,以后会动态修改.我的知识非常有限,不乏有些错误认识,不管怎样抛砖引玉分享出来,希

php结合redis实现高并发下的抢购、秒杀功能

原文: http://blog.csdn.net/nuli888/article/details/51865401 抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个:1 高并发对数据库产生的压力2 竞争状态下如何解决库存的正确减少("超卖"问题)对于第一个问题,已经很容易想到用缓存来处理抢购,避免直接操作数据库,例如使用Redis.重点在于第二个问题 常规写法: 查询出对应商品的库存,看是否大于0,然后执行生成订单等操作,但是在判断库存是否大于0处,如果在高并发下就会有问

高并发下的 Nginx 优化与负载均衡

高并发下的 Nginx 优化 英文原文:Optimizing Nginx for High Traffic Loads 过去谈过一些关于Nginx的常见问题; 其中有一些是关于如何优化Nginx. 很多Nginx新用户是从Apache迁移过来的,因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行. 有一些坏消息要告诉你, 你不能像Apache一样优化Nginx.它没有魔术配置来减半负载或是让PHP运行速度加快一倍. 高兴的是, Nginx已经优化的非常好了. 当你决定使用Nginx并用a

高并发下的Nginx优化

高并发下的Nginx优化 2014-08-08 13:30 mood Nginx 过去谈过一些关于Nginx的常见问题; 其中有一些是关于如何优化Nginx. 很多Nginx新用户是从Apache迁移过来的,因些他们过去常常调整配置和执行魔术操作来确保服务器高效运行. AD:2014WOT全球软件技术峰会北京站 课程视频发布 11月21日-22日 与WOT技术大会相约深圳 现在抢票 过去谈过一些关于Nginx的常见问题; 其中有一些是关于如何优化Nginx. 很多Nginx新用户是从Apache

MySQL 高可用架构在业务层面的应用分析

MySQL 高可用架构在业务层面的应用分析 http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&idx=1&sn=f9a0d03dd9a1cf3b3575c0241291e421&scene=22&srcid=seLU5tmZumKLzwVBIHzM#rd http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&am

php 结合redis实现高并发下的抢购、秒杀功能

抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个:1 高并发对数据库产生的压力2 竞争状态下如何解决库存的正确减少("超卖"问题)对于第一个问题,已经很容易想到用缓存来处理抢购,避免直接操作数据库,例如使用Redis.重点在于第二个问题 常规写法: 查询出对应商品的库存,看是否大于0,然后执行生成订单等操作,但是在判断库存是否大于0处,如果在高并发下就会有问题,导致库存量出现负数 [php] view plain copy <?php $conn=mysql_con

PHP开发中多种方案实现高并发下的抢购、秒杀功能

抢购.秒杀是如今很常见的一个应用场景,主要需要解决的问题有两个: 1 高并发对数据库产生的压力 2 竞争状态下如何解决库存的正确减少("超卖"问题) 对于第一个问题,已经很容易想到用缓存来处理抢购,避免直接操作数据库,例如使用Redis. 重点在于第二个问题. 常规写法: 查询出对应商品的库存,看是否大于0,然后执行生成订单等操作,但是在判断库存是否大于0处,如果在高并发下就会有问题,导致库存量出现负数 <?php $conn=mysql_connect("localh

记一个python+sqlalchemy+tornado的一个高并发下,产生重复记录的bug

场景:在用户通过支付通道支付完成返回时,发现我收到的处理数据记录中有两条同样的数据记录, 也就是同一笔钱,我数据库中记为了两条一样的记录. tornado端代码 from tornado import gen from tornado.concurrent import run_on_executor class processNetPay(BaseHandler): '''处理指定订单,指定支付请求,返回处理结果 ' 返回包含订单信息与用户信息体 ''' @tornado.web.asynch