如何应对大数据高并发

如何应对大数据高并发

• 增强服务器硬件配置
  • 增加cpu核心, 高速缓存, 频率
  • 增加内存容量, 频率
  • HDD换成SSD
  • 使用磁盘阵列
  • 使用高速网卡
  • 将双绞线换成光纤,甚至是背板
  • 使用专线
• 分流(主要指负载均衡)
  • DNS
  • CDN
  • F5
  • LVS
  • LBF
  • HAProxy
  • Nginx
  • 文件服务器
  • 动静分离
  • 数据库读写分离
  • 数据冷热分离
• 服务拆分
  • 分布式/微服务: 细粒度的服务拆分,方便按需进行伸缩
  • 数据库: 分库,分表
  • 前后端采用不同域名
• 服务治理(故障转移和服务伸缩)
  • 服务注册: zookeeper, etcd, consul
  • 服务发现: ocelot
  • 心跳检测
• 服务质量
  • 限流
  • 熔断
  • 降级
• 提前一切可提前的
  • 缓存预热
  • 异步刷新缓存(使用MQ或定时任务, 即事件调度和定时调度)
  • 站点预热: 动态内容静态化
• 延迟一切可延迟的
  • 使用MQ将一些不是那么重要的或无需同步执行完毕的计算任务,延迟执行
• 性能优化
  • 批量读写
  • 顺序读写
  • 减少网络IO
  • 减少磁盘IO
  • IO多路复用
  • 按需读写
  • 尽可能的将数据和计算资源放在较近的位置
  • 优化数据库索引,规范查询,必要时,可适当调整业务
  • 尽可能快速的释放不再需要的资源
  • 减少资源竞争
• 服务扩容
  • 服务集群化
  • RDB集群化
  • NoSQL集群化
  • 服务无状态化
  • 使用K8S对服务进行动态伸缩

案例总结:

我们以秒杀场景为例, 当大量用户请求进来时, 一个服务是扛不住的, 这时候我们想到的是分流, 就像现在打疫苗一样, 不同地区的人, 就近打疫苗, 如果全部去大医院, 或全部去北京打, 这个肯定是扛不住的; 当请求到达服务, 如果此时服务才开始准备数据, 势必会照成请求的拥塞, 所以我们需要提前将动态内容静态化, 就像我们打疫苗时, 是提前生产好的, 而不是打的时候再生产, 这样就可以加快速度; 为了提高并发, 我们一般取数据时, 比如库存, 不去数据库取, 而是从redis缓存取, 就像打疫苗时, 我们的疫苗是提前分发到疫苗服务网点, 然后直接在打疫苗的服务网点拿, 而不是去厂家或仓库拿一样; 当缓存中没有数据时, 我们会去数据库中取, 但是一个数据库可能存不下或无法提供非常高的查询请求, 此时我们就会去做数据的垂直拆分和水平拆分, 以提供更高的存储容量, 做读写分离, 以提高查询的并发, 就像疫苗多个厂家生产, 多仓库储存一样; 我们将生成订单和发送通知, 先生成一个消息发往MQ, 然后由其它服务处理一样, 就像我们打完第一针, 给个凭证(即消息), 等过个21天再来打第二针(即消费消息), 将无需同步执行的任务, 延时执行; 最后将订单信息落库, 将用户带到支付页面, 就像我们打完第二针, 会发另外一个凭证, 方便出行一样.