关于分布式系统的思考

思考

分布式系统中，我们经常要设计容灾，考虑少了容灾性不好，考虑多了，实现复杂， 怎么样才是合适呢？

经验和结论

容灾可以分为几个等级

1. 某个单点或某个业务逻辑的异常可以监控到，在发生异常时 可以通过工具恢复生产。
2. 发生异常 ，参与人受到通知，自动处理异常。
3. 自动处理逻辑失效后，可以手动解决（包括降级自动处理逻辑和恢复生产）

满足以上等级即可。
但是为啥不能使用更高的等级，比如自动处理逻辑失效，也可以自动恢复？
更高等级的设计会带来新的问题，如果一直解决下去问题就会无穷尽，程序实现也会加倍复杂，测试场景和覆盖率也难以保证。
我觉得，还是结合工作中的经验和踩坑来说，慢慢消化吧。
就像你在学习某项新技术时，总是不知道从那入手，希望有没有一些经验和规律可帮助我。
学习一门技术按照掌握水平可以分为 了解，会用，熟练， 精通，贯通。

大致有以下阶段：

1. 学习一个完整的教程–了解
2. 实践演练-demo–会用
3. 做项目,专研晦涩难懂的问题–熟练
4. 总结经验，学会一些奇技淫巧.-- 精通
5. 研读源码，理解原理，设计初衷，融汇贯通–贯通

参数校验 发现异常参数怎么处理

1. 写日志 返回异常参数（有返回值）
2. 写日志，终止本次（如果是多步操作，还要考虑事务完整性）调用（无返回值，或不能向调用方传递，常见于 定时任务，canel同步程序）
3. 容忍 执行指定流程（常见于 切换脚本）

异常处理

异常小到代码bug，大到系统容灾，这边只讨论 项目异常

内部： 代码bug

系统： 断电，地震，被攻击，JVM，人为影响

外部： 数据库，缓存，模块服务

CheckedException

通常是公共组件，多人合作编写同一项目时用到

IO:检测到异常可以使用本地缓存。

其作用是特征标识，方式失效备援方案的选择，和问题的快速定位

对于方法中所用代码的 用 try-catch包裹这种方式，认为可用，但是不赞同，认为 可用公共代码来捕获异常

RuntimeException()

try{
//business

}

catch(Exception ex){
//写日志

// 失效备援 1 重试 2 回滚

}

finally{
//释放资源 conn, lock

}

单线程和多线程的场景 在发生 RuntimeException时 会终止么？

在常见的 douboo服务 ，和WEB服务中是什么现象？

方法逻辑

1. 参数校验
2. 业务逻辑处理
3. 执行结果处理

日志

1. 配置
2. 多文件记录
3. 日志级别
4. 异常日志
5. 要忠实的记录问题现场
6. 大业务标识，小业务标识，异常描述，入参