会议抢订

E-Meeting现状

1. 所有的请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢
2. 重复预订的问题（超卖）
3. APP,PC部署在一起了
4. 高峰期访问很慢

E-Meeting业务分析

1. 正常流程： 查询会议室->锁定会议室（创建会议室）->更新会议室信息->通知开会
2. 抢订流程： 定时开始->瞬时抢控->时间短，瞬时并发量高

E-Meeting技术挑战

1. APP抢订会议室时间短，并发访问量大的特点，解决方案是将APP接口独立部署
2. 负载压力，页面内容尽量静态化，用户请求不需要经过应用服务器
3. 重复预订的问题（超卖）采用数据库事务和行级锁
4. 前端： 扩容，限流，静态化
5. 后端： 内存 + 排队

E-Meeting架构设计

1. 尽量将请求拦截在系统上游
2. 会议室预订（读多写少）【总共有60个会议室有1000个人抢，只有60个成功，其他都是查询】
3. 把客户端逻辑放到数据库，避免网络延迟和GC影响
4. 整个事务在数据库端完成，用存储过程写业务逻辑，服务端负责调用
5. 保证减完不能等于负数 update number set x=x-1 where (x -1 ) >= 0;

E-Meeting站点层设计

1. 按钮防重复（点击一次按钮后就变成灰色，禁止重复点击按钮）
2. 同一个UID，限制访问频度，做页面缓存，X秒内到达站点层的请求，均返回同一页面
3. 同一个item的查询，做页面缓存，X秒内到达站点层的请求，均返回同一页面
4. 同一个IP限制访问频度，做页面缓存

E-Meeting服务层设计

1. APP接口加入了10秒只能访问10次，之后再等10秒访问的限流操作
2. 对于写请求，做请求队列,如果库存不够全部返回“已售完”
3. 预处理阶段，把不必要的请求直接驳回

E-Meeting部署架构

1. 使用Nginx或Apache将用户的请求分发到不同的机器上做 负载均衡
2. 使用Redis减少数据库的请求量
3. 调整IIS 7应用程序池队列长度 由原来的默认1000改为65535
4. 调整IIS 7的appConcurrentRequestLimit设置 由原来的默认5000改为100000
   c:windowssystem32inetsrvappcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
5. 调整machine.config中的processModel>requestQueueLimit的设置由原来的默认5000改为100000。
6. 修改注册表，调整IIS 7支持的同时TCPIP连接数 由原来的默认5000改为100000。
   reg add HKLMSystemCurrentControlSetServicesHTTPParameteris /v MaxConnections /t REG_DWORD /d 100000

E-Meeting运营维护

1. 为了确保高峰期服务器资源足够支撑业务需要每天晚上0时重启IIS，短信服务，数据库IO清理的工作
2. 检查Oracle数据库性能是否达标
3. 高峰期的时间段检查网络稳定，Ping网络
4. 高峰期的时间段检查内存，CPU 是否过高