技术指标：

PV(Page View, 页面浏览量)在千万级别
QPS(Query Per Second, 每秒处理请求数)在百万级别
数据量在千亿级别
接口响应速度不能超过150毫秒
用户提交请求到页面呈现不能超过3秒

架构设计：
1. 从LAMP架构转为面向服务架构（服务可以用多种开发语言实现，不受一种开发语言限制）
2. 对海量数据做Sharding分片，分库分表
3. 从有状态服务改为无状态接口服务（便于分布式部署）
4. 精心设计的数据层（存储、压缩、索引）
5. 分布式系统最终瓶颈（CPU、内存、存储、网络）
6. 日志服务化，每个服务可以用不同的开发语言，考虑多种开发语言的兼容性，定义标准化的日志是把分布在不同机器上的日志关联起来的唯一且有效的办法
7. 对请求入口做负载均衡后再到达应用层

页面优化：
1. 静态文件压缩，优化HTTP请求连接数，以减少宽带需求，让页面更快加载出来
2. 静态资源做CDN部署
3. 前后端做数据分离，让搜索服务解耦，在高并发情况下更灵活做负载均衡
4. 后端数据大部分来自缓存，加载快，给用户更快的体验

数据层架构优化：
1. 商品详情、商品库存等，可以放在redis缓存，避免频繁去数据库取数据，提高商品信息的读能力
2. 数据库读写分离，分库分表实现负载均衡
3. 如果数据库有查询缓存功能，则使用数据库查询缓存功能（Query Cache功能，如果使用，记得定时清理碎片：Flush Query Cache）
4. 其他数据库细节优化（参考其他网络文章）

系统层优化：
1. 修改linux内核参数，适应高并发场景（具体参考网络相关文章）

业务优化：
秒杀和抢购收到了“海量”的请求，实际上里面的水分是很大的。有很多是第三方抢购辅助工具发送的请求，这些都是属于作弊的手段。

作弊方法和防御方法：
1. 作弊行为：同一个帐号，一次性发出多个请求
防御方法：在程序入口处，1个帐号只允许接收一个请求，其他请求过滤。或者，自己实现一个服务，将同一个账号的请求放入一个队列中，处理完一个，再处理下一个。

2. 多个账号，一次性发送多个请求
很多帐号注册功能，在发展早期是没有任何限制的，很容易就能注册很多个帐号。因此，一些特殊的工作室会编写自动注册脚本，积累一大批“僵尸帐号”（微博中的僵尸粉），数量庞大，专门做各种“刷”的行为，如抢购、刷票、转发抽奖等。
防御方法：
1).使用创新的验证码，比如回答问题或者执行某些简单的操作，把真实的用户和辅助工具区分来开。
2).直接禁止IP，虽然可能导致误伤，但是在实际场景中可以获得很好的效果。

3. 多个帐号，多个IP发送不同请求
“灰色工作室”发现单机IP请求频率被控制后，他们有的新的进攻方案：不断变换IP。（IP来源有随机代理IP、被植入木马的肉鸡，数量庞大等）
防御方法：这种场景下的请求，已经很难分辨出真实用户或辅助工具。通常只能通过设置业务门槛来限制这种请求，或者通过帐号行为的“数据挖掘”来提前清理它们。
僵尸帐号有一些共同的特征，就是帐号很可能属于同一号码段，甚至是连号，活跃度不高，等级低，资料不全等。根据这些特点，适当设置参与门槛，例如限制参与的帐号等级等。通过这些方法，也可以过滤掉一部分僵尸帐号。
（黄牛账号也是有一些共同特征的，例如经常抢票和退票，节假日异常活跃等）

结语：我们的挑战都一样，就是数据量，bigger and bigger，用户体验是faster and faster，业务是more and more。

参考文章：
http://www.cnblogs.com/zhenghui317/p/5577345.html
http://mt.sohu.com/it/d20170403/131798804_255931.shtml
http://blog.csdn.net/xiaemperor/article/details/38234979
http://www.cnblogs.com/dinglang/p/6133501.html
http://blog.csdn.net/qq_34341290/article/details/53316173

高并发高性能场景(抢购、秒杀、抢票、限时竞答)解决方案