/fenix_architecture_book

《凤凰架构:构建可靠的大型分布式系统》勘误

《凤凰架构:构建可靠的大型分布式系统》勘误

本工程为《凤凰架构:构建可靠的大型分布式系统》纸质书的勘误,根据读者反馈持续更新,可通过issues提交新的勘误。 本仓库仅作勘误之用,如对书籍具体内容有建议或疑惑,欢迎到本书主页(https://icyfenix.cn/)对应章节的页面中提出。

勘误列表:

  • Page 147:那把令牌放到内存里面,压根不考虑持久化【那是】最理想的方案。
    更正:那把令牌放到内存里面,压根不考虑持久化【才是】最理想的方案。

  • Page 158:而讽刺的是,由于停止后许多政府网站【被无法被浏览】
    更正:而讽刺的是,由于停止后许多政府网站【无法被浏览】

  • Page 208:【只许】设置一两个开关参数就可以开启对某个服务甚至全部服务的重试机制
    更正:【只需】设置一两个开关参数就可以开启对某个服务甚至全部服务的重试机制

以下勘误内容已在第4次重印版(2021-11-17日)修正


  • Page 2:此时的微型计算机系统通常具有 16 位寻址能力、不足 5MHz 时钟频率的处理器和 128 KB 左右的内存地址空间。
    这句话容易引起误解,修改为:
    此时的微型计算机系统通常具有 16 位寄存器、不足 5MHz 时钟频率的处理器,不超过 1 MB 的最大内存和 64KB 单段偏移地址

  • Page 59:这可能是相对【重负载操作】
    更正:这可能是相对【重负载的操作】

  • Page 137:这页有3处【隐私授权】,均为笔误,应为【隐式授权】

  • Page 166:如果使用三块硬盘存储则是【0.00125%】,四块是 【0.0000625%】,换而言之,这已经保证了数据在一年内有超过【99.9999%】的概率是安全可靠的
    更正:如果使用三块硬盘存储则是【0.0125%】,四块是 【0.000625%】,换而言之,这已经保证了数据在一年内有超过【99.999%】的概率是安全可靠的

  • Page 225-226:【JKWS】 顾名思义就是一组 JWK 的集合,支持 【JKWS】 的系统……
    更正:【JWKS】 顾名思义就是一组 JWK 的集合,支持 【JWKS】 的系统……

以下勘误内容已在第3次重印版(2021-9-12日)修正


  • Page 201:表8-1:出错的地方在一定时间【类】不可用
    更正:出错的地方在一定时间【内】不可用

  • Page 320-321:# 访问模式为【RXO】\ # 支持【RXO】访问模式
    更正:# 访问模式为【RWO】 \ # 支持【RWO】访问模式

  • Page 363-364:有3处【UDPA】笔误写成了【UDAP】,请编辑下次重印时修正一下。

以下勘误内容已在第2次重印版(2021-8-25日)修正


  • Page 231:通过财报上的营收、净利、毛利、资产、【负载】
    更正:通过财报上的营收、净利、毛利、资产、【负债】

  • Page 40:Google API 【Deign】 Guide
    更正:Google API 【Design】 Guide

以下勘误内容已在第1次重印版(2021-8-15日)修正


  • Page 28:笔者曾经在“原始分布式时代”中介绍过 【DEC】,这是历史上第一次对分布式有组织的探索尝试,由于 【DEC】 本身是基于 UNIX 操作系统的,所以 【DEC】/RPC 通常也仅适合于 UNIX 系统程序之间使用
    更正:笔者曾经在“原始分布式时代”中介绍过 【DCE】,这是历史上第一次对分布式有组织的探索尝试,由于 【DCE】 本身是基于 UNIX 操作系统的,所以 【DCE】/RPC 通常也仅适合于 UNIX 系统程序之间使用

  • Page 30:【DEC】/RPC 与 ONC RPC 都有很浓厚的 Unix 痕迹
    更正:【DCE】/RPC 与 ONC RPC 都有很浓厚的 Unix 痕迹

  • Page 42:POST /appointmentService?action=【comfirm】 HTTP/1.1
    更正:POST /appointmentService?action=【confirm】 HTTP/1.1

  • Page 76:同时依【然能够或者在】绝大多数时候保证处理结果的准确性
    更正:同时依然【能够在】绝大多数时候保证处理结果的准确性

  • Page 269:这个容器是整个 Pod 中第一个启动的容器,只有【几十万字节】大小(代码只有很短的几十行,
    更正:这个容器是整个 Pod 中第一个启动的容器,只有【几百 KB】大小(代码只有很短的几十行,
    (上面这些英文都不应该进行翻译,我复审的时候没有检查出来)

  • Page 212:TCP 协议的【阻塞控制(Congestion Control)】
    更正:TCP 协议的【流量控制(Flow Control)】

  • Page 234:再譬如,当前方法的返回值是个【映射】,开发期的调试数据只做了三五个【实体】,觉得遍历一下把具体内容打到日志里面没什么问题,到了生产期,这个【映射】里面有可能存放了成千上万个【实体】,这时候打印日志就相当于引用慢操作
    更正:再譬如,当前方法的返回值是个【Map】,开发期的调试数据只做了三五个【Entity】,觉得遍历一下把具体内容打到日志里面没什么问题,到了生产期,这个【Map】里面有可能存放了成千上万个【Entity】,这时候打印日志就相当于引用慢操作
    (上面这些英文都不应该进行翻译,我复审的时候没有检查出来)

  • Page 279:从 2018 年起,Helm 项目被托管到 【CNFC】
    更正:从 2018 年起,Helm 项目被托管到 【CNCF】

  • Page 351:或者代理主动从【约定的好的】位置获取
    更正:或者代理主动从【约定好的】位置获取

  • Page 378:可见族群运作的复杂度【就越高】,治理难度也越高。
    更正:可见族群运作的复杂度【越高】,治理难度也越高。