https://github.com/collabh/highconcurrent
https://github.com/collabh/highconcurrent
Last synced: 2 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/collabh/highconcurrent
- Owner: collabH
- Created: 2019-05-07T12:25:15.000Z (about 7 years ago)
- Default Branch: master
- Last Pushed: 2019-05-07T12:27:01.000Z (about 7 years ago)
- Last Synced: 2025-03-14T15:39:35.069Z (over 1 year ago)
- Language: Java
- Size: 177 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# 高并发
## 扩容
* 垂直扩容(纵向扩展):提高系统部件能力
* 水平扩容(横向扩展):增加更多系统成员来实现
## 扩容-数据库
* 读操作扩展:memcache、redis、CDN等缓存
* 写操作扩展:Cassandra、Hbase等
## 缓存
**缓存特征**
* 命中率:命中数/(命中数+没有命中数)
* 最大元素(空间)
* 清空策略:FIFO,LFU,LRU,过期时间，随机
**缓存命中率影响因素**
* 业务场景和业务需求
* 缓存的设计(粒度和策略)
* 缓存的容量和基础设施
**缓存分类和应用场景**
* 本地缓存：编程实现(成员变量、局部变量、静态变量)、Guava Cache
* 分布式缓存：Memcache、Redis
**缓存一致性**
>更新数据库成功->更新缓存失败->缓存不一致
>更新缓存成功->更新数据库失败->缓存不一致
>更新数据库成功->淘汰缓存失败->缓存不一致
>淘汰缓存成功->更新数据库失败->缓存不一致
**解决缓存穿透**
* 缓存空对象，如果查询为空的话可以缓存空对象，需要保存时效性
* 对所有可能为空的key在请求做拦截 bitmap
## 消息队列
**为什么需要消息队列**
* 【生产】和【消费】的速度或稳定性等因素不一致
**消息队列好处**
* 业务解耦（关心通知）
* 最终一致性
* 广播
* 错峰与流控
## 应用拆分
**基本原则**
* 业务优先（按照业务边界进行切割，再按照模块进行拆分）
* 循序渐进（拆分和测试，边拆分边测试，保证拆分是完整的）
* 兼顾技术：重构、分层
* 可靠测试
**应用拆分-思考**
* 应用直接的通信：RPC(dubbo等 实时性更高)、消息队列
* 应用之间数据库设计：每个应用都有独立的数据库
* 避免事务操作垮应用
## 应用限流
**限流算法**
* 计数器法 需要考虑临界
* 滑动窗口 需要更多的存储空间
* 漏桶算法
* 令牌桶算法 允许流量的突发
# 服务降级与服务熔断
* 服务降级--定制不同的默认和错误
* 自动降级：超时、失败次数、故障、限流
* 人工降级：秒杀、双11大促等
* 服务熔断--某个原因使得服务过载后，会在一段时间是服务熔断
* 共性：目的、最终表现、力度、自治
* 区别：触发原因、管理目标层次、实现方式
# Hystrix
* 通过第三方客户端访问(通常是通过网络)依赖服务出现高延迟或者失败时，为系统提供保护和控制
* 在分布式系统中防止级联失败
* 快速失败(Fail fast)同时能快速恢复
* 提供失败回退(Fallback)和优雅的服务降级机制
# 数据库切库、分库、分表
* 数据库瓶颈
* 单个库数据量太大(1T-2T):多个库
* 单个数据库服务器压力过大、读写瓶颈:多个库
* 单个表数据量过大：分表
**数据库切库**
* 切库的基础及实际运用：读写分离 (减轻主库的压力、使用动态数据源)
* 自定义注解完成数据库切库-代码实现
**数据库支持多个数据源与分库**
* 支持多数据源、分库
**数据库分表**
* 什么时候考虑分表
* 水平分表与垂直分表
* 数据库分表：mybatis分表插件shardbatis2.0
# 高可用的一些手段
* 任务调度系统分布式：elastic-job+zookeeper
* 主备切换：apache curator+zookeeper分布式锁实现
* 监控报警机制