设计之初, 一定要问这两个问题
- 高并发 到底有多高, 这个是很不一样的
- 数据一致性的要求有多高
- 削峰 那么做削峰处理的服务(nginx), 必须能抗住最高峰值的流量
如果并发量高于5w, 那么一台nginx扛不住
1. 通过划分域名, 分流主站的流量
down.qq.com 由down服务器集群去承担down业务的流量
games.qq.com 由games服务器集群去承担games业务的流量
2. 如果games.qq.com流量依然很高
N个nginx + M个tomcat依然扛不住
那就用CDN, 10年前就有了的非常成熟的产品, 比如阿里云就有类似的产品
CDN可以缓存静态资源, 以及少量的动态缓存 ( 一致性要求低 )
这是第一层缓存, 可以极大的降低打入业务系统的请求量
一致性要求低的场景
- 比如电商系统的搜索, 前几页一定是做了缓存的
- 比如搜"手机", 前5页做缓存, 在510分钟内, 业务后台只需要处理一次请求
- 实现方式是: 定时任务每隔5分钟去搜ES, 把读取到的结果, 写入缓存
- 缓存越前置, 性能越高, 缓存在JVM肯定不如缓存在nginx, nginx也肯定不如缓存在CDN
- 另外, 北京的用户搜索结果, 可以缓存在位于北京的CDN, 上海的可以缓存在上海
- 大型系统里, 类似的定时任务少则几百, 大则几千, 是很常用的解决方案
Nginx无法直接操作Redis, 所以需要Lua脚本
针对读请求的 高并发系统架构
Nginx缓存
1. http_proxy_cache 本地磁盘缓存
2. lua-resty-lrucache
3. nginx全局内存缓存
商品数据C端展示逻辑
商品编辑审核通过 -> MQ消息 -> C端商品Consumer -> 对于静态字段, 生成静态页面, 价格/库存这种动态信息, 生成另一份, 同步到各cdn网络上, 然后利用ajax页面局部刷新, 设置库存/价格等频繁变动的信息
问题是: 商品数量过多怎么办?
5000个商详静态页面, 2秒完成, 那5000万个就需要2万秒