掘友等级
获得徽章 6
亚马逊可以微信登录了
**常见的 NoSQL 方案**
* K-V 存储:解决关系数据库无法存储数据结构的问题,以 Redis 为代表。
* 文档数据库:解决关系数据库强 schema 约束的问题,以 MongoDB 为代表。
* 列式数据库:解决关系数据库大数据场景下的 I/O 问题,以 HBase 为代表。
* 全文搜索引擎:解决关系数据库的全文搜索性能问题,以 Elasticsearch 为代表。
# FEMA
FMEA(Failure mode and effects analysis,故障模式与影响分析)又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等
## FMEA 方法
* 给出初始的架构设计图。
* 假设架构中某个部件发生故障。
* 分析此故障对系统功能造成的影响。
* 根据分析结果,判断架构是否需要进行优化。
FMEA 分析表格:
1. 功能点:用户角度、
2. 故障模式:量化描述、故障点和故障形式(不需要写原因)
3. 故障影响:功能点受到的影响(功能点响应缓慢、功能点出错等),尽量量化
4. 严重程度:致命 / 高 / 中 / 低 / 无。框架化思维(严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度)
5. 故障原因:不同故障发生概率不同、监测手段不一样、处理措施不一样
6. 故障概率:高 / 中 / 低。考虑点,硬件、开源系统、自研系统
7. 风险程度 = 严重程度 × 故障概率
8. 已有措施:检测告警、容错、自恢复
9. 规避措施:为了降低故障发生概率而做的一些事情。技术手段、管理手段
10. 解决措施:为了能够解决问题而做的一些事情
11. 后续规划:哪些故障我们目前还缺乏对应的措施,哪些已有措施还不够,针对这些不足的地方,再结合风险程度进行排序,给出后续的改进规划。
# 故障处理
## 事前准备
- **以用户功能为索引的服务和资源的全视图。**以用户端的功能来做索引的。然后,把后端的服务、服务的调用关系,以及服务使用到的资源都关联起来做成一个视图。如:zipkin
- **为地图中的各个服务制订关键指标,以及一套运维流程和工具,包括应急方案**。以用户功能为索引,为每个用户功能的服务都制订一个服务故障的检测、处理和恢复手册,以及相关的检测、查错或是恢复的运维工具。对于基础层和一些通用的中间件,也需要有相应的最佳实践的方法。
- **设定故障的等级。**
- **故障演练。**
- 线上使用**灰度发布系统或A/B测试**。
## 事中处理
出现故障时,最重要的不是 debug 故障,而是尽可能地**减少故障的影响范围**,并尽可能快地修复问题。
应对措施:
- 重启和限流。
- 回滚操作。
- 降级操作。
- 紧急更新。
## 事后复盘
- Ask 5 Whys(问5个跟故障相关的问题,并查明解决)
- 所有相关人员到齐复盘(透明化,更易搞懂问题)
## 根除问题本质
一个技术问题,后面隐藏的是工程能力问题,工程能力问题后面隐藏的是管理问题,管理问题后面隐藏的是一个公司文化的问题,公司文化的问题则隐藏着创始人的问题
1. **举一反三解决当下的故障**。为自己赢得更多的时间。
2. **简化复杂、不合理的技术架构、流程和组织**。你不可能在一个复杂的环境下根本地解决问题。
3. **全面改善和优化整个系统,包括组织**。解决问题的根本方法是改善和调整整体结构。而只有简单优雅的东西才有被改善和优化的可能。
负载均衡分类
## DNS负载均衡
DNS 负载均衡的本质是 DNS 解析同一个域名可以返回不同的 IP 地址
优点:
- 简单、成本低
- 就近访问,提升访问速度
缺点:
- 更新不及时
- 扩展性差:DNS 负载均衡的控制权在域名商那里,无法根据业务特点针对其做更多的定制化功能和扩展特性。
- 分配策略比较简单:DNS 负载均衡支持的算法少;不能区分服务器的差异(不能根据系统与服务的状态来判断负载);也无法感知后端服务器的状态。
对于**时延和故障敏感**的业务,有一些公司自己实现了** HTTP-DNS** 的功能
## 硬件负载均衡
目前业界典型的硬件负载均衡设备有两款:**F5 和 A10**。
优点:
- 功能强大:全面支持各层级的负载均衡,支持全面的负载均衡算法,支持全局负载均衡。
- 性能强大:对比一下,软件负载均衡支持到 **10 万级**并发已经很厉害了,硬件负载均衡可以支持 **100 万**以上的并发。
- 稳定性高:商用硬件负载均衡,经过了良好的严格测试,经过大规模使用,稳定性高。
- 支持安全防护:硬件均衡设备除具备负载均衡功能外,还具备防火墙、防 DDoS 攻击等安全功能。
缺点:
- 价格昂贵:最普通的一台 F5 ,价格也要数十万
- 扩展能力差
## 软件负载均衡
Nginx 是软件的 7 层负载均衡,LVS 是 Linux 内核的 4 层负载均衡。 4 层和 7 层的区别就在于协议和灵活性,Nginx 支持 HTTP、E-mail 协议;而 LVS 是 4 层负载均衡,和协议无关,几乎所有应用都可以做
软件和硬件的最主要区别就在于**性能**
优点:简单、便宜、灵活
缺点(与硬件比较):性能一般、不具备安全防护功能、功能一般
负载均衡分类
## DNS负载均衡
DNS 负载均衡的本质是 DNS 解析同一个域名可以返回不同的 IP 地址
优点:
- 简单、成本低
- 就近访问,提升访问速度
缺点:
- 更新不及时
- 扩展性差:DNS 负载均衡的控制权在域名商那里,无法根据业务特点针对其做更多的定制化功能和扩展特性。
- 分配策略比较简单:DNS 负载均衡支持的算法少;不能区分服务器的差异(不能根据系统与服务的状态来判断负载);也无法感知后端服务器的状态。
对于**时延和故障敏感**的业务,有一些公司自己实现了** HTTP-DNS** 的功能
## 硬件负载均衡
目前业界典型的硬件负载均衡设备有两款:**F5 和 A10**。
优点:
- 功能强大:全面支持各层级的负载均衡,支持全面的负载均衡算法,支持全局负载均衡。
- 性能强大:对比一下,软件负载均衡支持到 **10 万级**并发已经很厉害了,硬件负载均衡可以支持 **100 万**以上的并发。
- 稳定性高:商用硬件负载均衡,经过了良好的严格测试,经过大规模使用,稳定性高。
- 支持安全防护:硬件均衡设备除具备负载均衡功能外,还具备防火墙、防 DDoS 攻击等安全功能。
缺点:
- 价格昂贵:最普通的一台 F5 ,价格也要数十万
- 扩展能力差
## 软件负载均衡
Nginx 是软件的 7 层负载均衡,LVS 是 Linux 内核的 4 层负载均衡。 4 层和 7 层的区别就在于协议和灵活性,Nginx 支持 HTTP、E-mail 协议;而 LVS 是 4 层负载均衡,和协议无关,几乎所有应用都可以做
软件和硬件的最主要区别就在于**性能**
优点:简单、便宜、灵活
缺点(与硬件比较):性能一般、不具备安全防护功能、功能一般
常见缓存问题
## 缓存穿透
缓存穿透是指缓存没有发挥作用,业务系统虽然去缓存查询数据,但缓存中没有数据,业务系统需要再次去存储系统查询数据。
解决方案:设置默认值
## 缓存雪崩
缓存雪崩是指当缓存失效(过期)后引起系统性能急剧下降的情况。
解决方案:
**更新锁**
对缓存更新操作进行加锁保护,保证只有一个线程能够进行缓存更新,未能获取更新锁的线程要么等待锁释放后重新读取缓存,要么就返回空值或者默认值。
**后台更新**
由后台线程来更新缓存,而不是由业务线程来更新缓存,缓存本身的有效期设置为永久,后台线程定时更新缓存。
内存不够时,缓存被“踢掉”造成读取空值的解决方案:
1. 后台定时更新缓存
2. 业务发送消息提醒后台更新缓存
## 缓存热点
对于一些特别热点的数据,如果大部分甚至所有的业务请求都命中同一份缓存数据,则这份数据所在的缓存服务器的压力也很大。
方案:复制多份缓存副本,将请求分散到多个缓存服务器上
精力管理的几种方法:
1、减少内耗
2、学会聚焦,降低任务切换频率
3、学会真正的休息,找到最适合自己的休息方式
**学会说“不”**
1. 不要立即说“不”,而是稍微研究后再说。
2. 满足部分需求。
3. 当面对时间完全不够的需求时,也不要说不,要想办法把这个压力还回去
- 我可以加班加点完成,但是我不保证好的质量,有 bug 你得认,而且事后你要给我 1 个月的时间还债
- 我可以加班加点,还能保证质量,但我没办法完成这么多需求,能不能减少一些?
- 我可以保质保量地完成所有的需求,但是,能不能多给我 2 周时间?
js预处理var、function、class的不同:
var 作用域提升只认脚本、模块和函数体三种语法结构
function 作用结构跟var相同,还会给它赋值。
class 存在局部作用域,在作用域中创建变量,并且要求访问它时抛出错误。
下一页