1. 以前“计划内的停机”很正常，现在则不被接受2. 高可用性架构2.1. CF系统不会遇到任何常见的单点失效问题2.1.1. 硬件的每一部分都有冗余2.1.1.1. CPU2.1.1.2. 驱动器2.1.1.3. 网卡2.1.1.4. 电源2.1.1.5. 网络交换机2.1.1.6. 风扇2.1.2. 为了防止某个机架受到损坏或破坏，服务器甚至被分散安装到不同的机架上2.1.3. 如果发生火灾、洪水、炸弹袭击，位于48千米外的第2个机房可以随时把系统接管过去3. 集群配置的常见问题3.1. 没有足够的心跳3.2. 心跳数据和生产数据由相同的交换机传输3.3. 服务器设置为使用物理IP地址而不是虚拟IP地址3.4. 设计的软件包之间混乱的依赖关系4. 遭遇停机4.1. 首要的任务都是恢复服务4.2. 要先恢复服务，之后才是调查原因4.2.1. 数百种疾病都能引起发烧4.2.2. 为了判断可能的病因，需要进行化验或观察，了解更多信息5. 事后分析5.1. 谁最后动的就赖谁5.1.1. post hoc, ergo propter hoc5.1.2. 由于在数据库故障切换和维护之后，系统很快就失效了，因此疑点自然聚焦在故障切换操作上5.2. 可靠的线索5.2.1. 在停机事故发生时复制下来的服务器日志5.2.1.1. 软件事故的事后分析实际上更难完成，因为事件结束了，没有留下可供分析的实物5.2.2. RMI使得跨机器之间的通信方式就像在本机内部通信，但这种方式无法为通信调用设置超时时间，所以有一定的风险5.2.2.1. 调用方很容易被其调用的远程服务器中的问题拖垮5.3. 不可靠的线索5.3.1. 人们对所见之事的陈述6. 原因6.1. JDBC规范允许java.sql.Statement.close()抛出一个SQLException异常，所以代码必须处理该异常6.1.1. 如果在关闭statement时抛出异常，则数据库连接不会被关闭，从而导致资源泄漏6.1.2. 这个异常在正常情况下几乎是不会被抛出来的6.1.2.1. 当Oracle驱动程序在遇到IOException的情况下尝试关闭数据库连接时，例如执行数据库故障切换，SQLException异常就会抛出6.1.2.2. 在执行该statement语句进行一些网络I/O操作时，会抛出SQLException异常。而在关闭该statement语句时也会抛出SQLException异常，因为驱动程序会尝试告诉数据库服务器释放与该语句相关的资源6.2. 假设JDBC连接是在故障切换之前创建的6.2.1. 当数据库服务器执行故障切换时，用于创建连接的数据库服务器IP地址将从一台主机变成另一台主机，但TCP连接的当前状态不会将数据库主机地址转变为第二个主机地址6.2.2. 任何对套接字的写入操作，最终都会抛出一个IOException异常6.2.3. 意味着资源池中的每个JDBC连接都是能引发事故的“地雷”6.3. 被迫停飞的原因只是一个未被捕获的SQLException异常7. 预防管用吗7.1. 指望着每一个像这样的软件缺陷最终都能被揪出来，就是天方夜谭7.2. 除非其中一位代码评审员知道Oracle JDBC驱动程序的内部实现细节，或者代码评审团队对每个Java方法都花费几个小时来评审，否则是不会发现的7.3. 只有在知道问题的情况下，编写发现问题的测试才会变得简单7.3.1. 在定位了问题之后，该团队在压力测试环境中进行了测试，确实重现了同样的差错7.4. 系统中的一个软件缺陷可能会传播到所有其他受影响的系统中7.4.1. 每个企业内部都有相互关联和相互依赖的系统7.4.2. 不能允许软件缺陷导致一连串的系统失效
以上就是朝夕生活（www.30zx.com）关于“读发布！设计与部署稳定的分布式系统第2版笔记02_停飞的代码异常”的详细内容，希望对大家有所帮助！
