基于redis高并发程序设计.ppt

基于Redis的高并发程序设计 --电商类秒杀、抢购、预约投资场景的解决方案 2015年11月26日 通用技术组-张晓明 提纲 一：背景 二：技术选型 三：设计思路及折衷 四：系统功能设计 五：系统架构设计 六：服务器部署 七：数据库设计 八：数据初始化及抢购流程 九：其他方案-理财预约投资方案 通用技术组 一、背景 通用技术组 对电商类项目的秒杀、抢购、预约理财等高并发场景进行抽象，设计出有针对性的系统架构，以支撑此类场景的业务需求。 1.设计的目标 能支撑4万并发请求（QPS）。 2.实现的功能 前台商品展示；商品抢购、秒杀；后台管理。 3.性能指标及数据量预估 用户总量3000万，活跃用户30万，同时在线 3万，日请求量1亿+。 接口响应时间200ms以内， 所有接口响应时间不超过500ms。 系统能支撑40000 QPS的压力。 4.难点 高并发、数据一致性、反作弊 二、技术选型 通用技术组 技术选型- LTMRP Linux： 公司标准型服务器 16核 16G内存 CentOS6.5 内核 2.6.32-431.el6.x86_64 有条件的可以用PAAS平台，以提高扩容的灵活性和及时性。 Tengine：经过淘宝、天猫高并发检验，兼容Nginx且比Nginx更高效、稳定、灵活 MySQL：关键数据需要持久化到MySQL数据库中 MySQL5.5 （InnoDB，单机1w+ Read/Sec，4k~1.5wWrite/Sec MaxConnection 1.5k） Redis： 高效、灵活，适用于高并发场景 Redis3.0 （单机10G内存） PHP： PHP5.5（php-fpm） 框架： 轻型PHP框架，敏捷开发 Yaf、ThinkPHP 三、设计思路及折衷 通用技术组 支撑4w QPS分析 认为瓶颈可能在WebServer、MySQL、Redis 1）WebServer方面 采用比Nginx更高效、稳定、易用的Tengine+php-fpm 公司标准服务器 16G内存，每个php-fpm进程占用20M左右，单台大约能起 800个php-fpm进程。 接口响应时间控制在200ms以内，复杂接口响应时间不超过500ms。 综上单台服务器理论QPS能达到4000，能支撑4wQPS需要10台WebServer 2）Redis方面 利用Redis敏捷高效的特性，将请求压力落到Redis上，以保证接口的响应时间 Redis业界压测数据为单机读写8~10w QPS，预计每个请求读写次数为4~5次， 2台即可支撑。 3）MySQL方面 MySQL5.5（InnoDB，单机1w 读/Sec，4k~1.5w写/Sec 最大连接数1.5k ）， 预计三、四台机器即可支撑。 四、系统功能设计 通用技术组 1.前台 前端静态资源采用CDN加速。 前台登录模块采用Passport服务。 2.后台 后台权限由OA+一点登录系统提供服务并利用VPN（IP白名单）进行访问限制 商品图片等信息由搜索组提供的上传接口以及存储服务保证。 日志分析以及数据统计由数据中心提供服务。 3.接口 首先经过WAF安全过滤。 其次经过前端转发机进行请求分发，做到负载均衡。 程序方面对请求进行反作弊过滤。 4.数据存储 商品、订单以及用户信息需要持久化到MySQL表中。 通过后台将MySQL数据load到Redis中，Redis中的数据是非敏感数据，为了以 防万一，需额外提供容灾策略（比如关键数据需Redis+MySQL双写，跑脚本定时 持久化到MySQL中）。 四、系统功能设计 通用技术组 5.数据一致性 a.如何避免商品超发 首先在后台设置，将一定数量的商品生成对应的一组数据（MySQL，每条记录有个唯一ID ），并将这组ID 利用Redis sadd到指定的集合中（rs:po:2115)，当并发抢购时spop出 一个随机预售ID给当前用户， 用户拿着这个ID去MySQL中查询比对，如果确实存在则利用select……for update 事 务查询并更新库存，生成订单，同时标