高并发系统开发（广州软件公司），高并发系统搭建，高并发APP开发
我们打算组织一个并发一万人的秒杀活动，1元秒杀100个二手元牙刷，你给我说说解决方案。
秒杀/抢购业务场景
商品秒杀、商品抢购、群红。包、抢优惠劵、抽奖、......
秒杀/抢购业务特点
秒杀商品价格低廉、抢购商品很好|抢手、大幅推广|广为人知、瞬时售空、一般是定时上架、持续时间短、瞬时并发量高......
秒杀、抢购技术特点
读多写少、高并发、资源冲突
知道这些，恭喜你，获得10分。
分析技术特点：
秒杀/抢购技术特点
1.读多写少
缓存
2.高并发
1.限流
2.负载均衡（单体tomcat并发200完美胜任，突破五，六百就力不从心）
3.缓存
4.异步（将同步的并发请求转换为异步）
5.队列
3.资源冲突
数据库锁
分布式锁
其他原子操作
乐观锁
悲观锁
redis
decr
原子操作
异步
原子操作和异步分为：
回答到这里，恭喜你，获得50分了，还没有及格。
系统基本架构
日均PV只有几万的企业管理系统
用户量过千万的中型技术社区
活跃用户过亿的大型购物网站
这三种都是这种架构：
一个系统基本架构
回答这一步，恭喜你，获得80分
秒杀人群、并发规模的预估
1.为什么要估算？
确定一个Zui终的技术选型以及服务器容量
2.怎么估算？
日并发估算的公式很很多
1) 平均并发用户数为 C = nl/T
2) 并发用户数峰值 C = C + 3 * 根号C
秒杀的并发规模就要根据公司活动历时依赖的Zui高峰值再扩容。
这里我们的并发需求在前面已经确定了。
我们打算组织一个并发1万人的秒杀活动，1元秒杀100个二手牙刷。
10000个并发的架构
悲观锁：select * from 表名 for update，该用户不提交，其他人都没法操作
乐观锁：在表里面加一个version字段，通过一个版本号去控.制
悲观锁VS乐观锁：
1.响应速度
2.冲突频率
3.重试代价
高并发情况下两个锁的结论：悲观锁速度更快！！！有时乐观锁偶然会比悲观锁低，在大数据的情况下，悲观锁会比乐观锁低！
悲观锁速度测试：
乐观锁速度测试：
