思考
分布式系统中,我们经常要设计容灾,考虑少了容灾性不好,考虑多了,实现复杂, 怎么样才是合适呢?
经验和结论
容灾可以分为几个等级
- 某个单点或某个业务逻辑的异常可以监控到,在发生异常时 可以通过工具恢复生产。
- 发生异常 ,参与人受到通知,自动处理异常。
- 自动处理逻辑失效后,可以手动解决(包括降级自动处理逻辑和恢复生产)
满足以上等级即可。
但是为啥不能使用更高的等级,比如自动处理逻辑失效,也可以自动恢复?
更高等级的设计会带来新的问题,如果一直解决下去问题就会无穷尽,程序实现也会加倍复杂,测试场景和覆盖率也难以保证。
我觉得,还是结合工作中的经验和踩坑来说,慢慢消化吧。
就像你在学习某项新技术时,总是不知道从那入手,希望有没有一些经验和规律可帮助我。
学习一门技术按照掌握水平可以分为 了解,会用,熟练, 精通,贯通。
大致有以下阶段:
- 学习一个完整的教程–了解
- 实践演练-demo–会用
- 做项目,专研晦涩难懂的问题–熟练
- 总结经验,学会一些奇技淫巧.-- 精通
- 研读源码,理解原理,设计初衷,融汇贯通–贯通
参数校验 发现异常参数怎么处理
- 写日志 返回异常参数(有返回值)
- 写日志,终止本次(如果是多步操作,还要考虑事务完整性)调用(无返回值,或不能向调用方传递,常见于 定时任务,canel同步程序)
- 容忍 执行指定流程(常见于 切换脚本)
异常处理
异常小到代码bug,大到系统容灾,这边只讨论 项目异常
内部: 代码bug
系统: 断电,地震,被攻击,JVM,人为影响
外部: 数据库,缓存,模块服务
CheckedException
通常是公共组件,多人合作编写同一项目时用到
IO:检测到异常可以使用本地缓存。
其作用是特征标识,方式失效备援方案的选择,和问题的快速定位
对于方法中所用代码的 用 try-catch包裹这种方式,认为可用,但是不赞同,认为 可用公共代码来捕获异常
RuntimeException()
try{
//business
}
catch(Exception ex){
//写日志
// 失效备援 1 重试 2 回滚
}
finally{
//释放资源 conn, lock
}
单线程和多线程的场景 在发生 RuntimeException时 会终止么?
在常见的 douboo服务 ,和WEB服务中是什么现象?
方法逻辑
- 参数校验
- 业务逻辑处理
- 执行结果处理
日志
- 配置
- 多文件记录
- 日志级别
- 异常日志
- 要忠实的记录问题现场
- 大业务标识,小业务标识,异常描述,入参