人人都是架构师：分布式系统架构落地与瓶颈突破-图书

推荐0
收藏7
浏览2.4K

人人都是架构师：分布式系统架构落地与瓶颈突破

高翔龙 (作者)　

书　　号：978-7-121-31238-0
出版日期：2017-05-05
页　　数：200
开　　本：16(185*235)
出版状态：上市销售

纸质版￥69.00

本书注重大型网站技术架构方案的落地，以及实战实施。本书不仅会从宏观的角度去阐述大型电商网站系统的架构设计，更重要的是，会结合笔者实际的工作经验，深入剖析大型电商系统最容易出现系统瓶颈的细节，并提供可实施方案。其中独特内容有：利用mq的消峰；大秒系统redis cluster的单点瓶颈；关系型数据库之sharding改造等。

真正的大型网站架构解决方案来了！

前言
本书的创作初衷
任何一本书，都是一个用于承载知识的载体，读者可以从中探寻自己想要知道的答案。对于我而言，书本就是带我领略奇妙计算机世界最快的一条途径。之所以想创作一本与大型分布式系统架构相关的书籍，是因为我在最近几年的实际工作中经历了太多的技术难题。每当我和我的团队尝试解决这些问题之前，时常想着能否从市面上现有的架构书籍中寻求到解决方案；但事与愿违，目前市面上高歌架构理论的读物居多，而真正讲解大型网站在架构演变过程中出现技术难题时应该如何解决的书籍却寥寥无几。对于这块领域的空白，我想尝试着去创作，尽量把我自己脑海中的内容写出来，让更多人受益，毕竟架构是需要落地的，否则便是一纸空谈。
本书内容重点
本书每一章的内容几乎都是独立的，大家完全可以挑选自己感兴趣或者有需要的部分进行阅读。本书一共包含5章，笔者首先从分布式服务案例开始讲起，将大家带进分布式系统的殿堂。在第1章中，笔者讲解了大型网站的架构演变过程，让大家对分布式系统建立一个基本的认识。当然，本章的重点是讲解企业在大规模服务化后应该如何实施服务治理，以及应该如何构建一个分布式调用跟踪系统，以一种可视化的方式来展现跟踪到的每一个请求的完整调用链，并收集调用链上每个服务的执行耗时，整合孤立日志等。
为了避免大促场景下峰值流量过大，对系统造成较大负载导致产生雪崩现象，笔者在本书的第2章为大家讲解了大流量限流/消峰案例，让系统的负载压力始终处于一个比较均衡的水位，从而保护系统的稳定运行。笔者首先从限流算法开始讲起，然后分享了业务层面和技术层面等两个维度的流量管制方案。当然，本章的重点是为大家演示如何通过MQ来实现大流量场景下的流量消峰。
本书的第3章为大家讲解了分布式配置管理服务案例（配置中心）。尽管目前一些中小型互联网企业仍然将本地配置作为首选，但是当网站发展到一定规模后，继续采用本地配置所暴露的问题将会越来越多。大型网站使用分布式配置管理平台不仅能够实现配置信息的集中式管理、降低维护成本和配置出错率，还能够动态获取/更新配置信息。本章的重点是为大家演示如何基于ZooKeeper构建一个分布式配置管理平台，以及使用淘宝Diamond和百度Disconf系统来实现分布式配置管理服务。
热点数据的读/写操作其实是秒杀、限时抢购场景下最核心的技术难题。在大促场景下，由于峰值流量较大，大量针对同一热卖商品的并发读/写操作一定会导致后端的存储系统产生性能瓶颈，因此第4章为大家讲解了大促场景下热点数据的读/写优化案例。尽管商品信息可以缓存在分布式缓存中，通过集群技术，可以在理论上认为其容量是无限的，但是对于大促场景下的热卖商品来说，由于单价比平时更给力、更具吸引力，因而自然会比平时吸引更大的流量进来；这时同一个Key必然会落到同一个缓存节点上，而分布式缓存在这种情况下一定会出现单点瓶颈，因此笔者为大家演示了如何实施多级Cache方案来防止分布式缓存系统出现单点瓶颈。由于写操作无法直接在缓存中完成，因此大量的并发更新热点数据（库存扣减）都是针对数据库中同一行的——本书以MySQL为例，而这必然会引起大量的线程来相互竞争InnoDB的行锁；并发越大时，等待的线程就越多，这会严重影响数据库的TPS，导致RT线性上升，最终可能引发系统出现雪崩。为了避免数据库沦为瓶颈，笔者为大家演示了如何通过分布式锁、乐观锁在分布式缓存系统中扣减库存、通过抢购限流控制单机并发写流量，以及如何使用阿里开源的AliSQL数据库提升“秒杀”场景性能。
在本书的最后一章，笔者为大家讲解了数据库分库分表案例。本章演示了如何通过分库分表中间件Shark来帮助企业实施分库分表改造，以及分库分表后所带来一系列影响的解决方案，并重点分享了笔者在实际工作中订单业务实施分库分表改造后，应该如何同时满足Buyer和Seller的多维度查询需求。
本书面向的读者
本书适用于任何对分布式系统架构感兴趣的架构师、开发人员以及运维人员。笔者尽量用通俗易懂的文字描绘本书的各个知识点，并引用了大量在实际工作中笔者遇到的那些真实案例，相信阅读本书时你将会有知其然并知其所以然的畅快感。
读者讨论
由于笔者能力有限，书中难免会出现一些错误或者不准确的地方，你可以通过邮箱gao_xianglong@sina.com将问题反馈给我，我会尽量对所有问题都给予答复。
致谢
首先我要感谢我们家莹宝宝，是你的支持和鼓励才让我有了继续创作下去的勇气。还记得在本书的创作过程中，每当我写完一节时，我都会“强迫”你高声朗读帮我梳理下笔的准确度；以及每当我头痛欲裂思绪全无时，你的陪伴点燃了我在每个凌晨的斗志；甚至在我烦躁时，你总是毫无怨言地忍受着我的“坏脾气”。谢谢你的包容和体贴，我爱你。
其次我要感谢我的团队：我的两位BOSS——冰冰和校长，最牛的MySQL DBA平哥，架构师大飞、青龙、小狼、僧哥、布爸，感谢你们平时在工作上的支持。
当然，本书能够顺利出版，离不开本书的两位编辑：孙学瑛老师和Anna老师的共同努力；感谢你们辛苦的文字校对工作，同时也祝愿孙学瑛老师家的猴宝宝健康茁壮地成长。
最后感谢那些曾经帮助过我的所有人，我爱你们！
高翔龙
2016年12月31日深夜

第1章分布式服务案例 1
1.1 分布式系统的架构演变过程 2
1.1.1 单机系统 3
1.1.2 集群架构 4
1.1.3 拆系统之业务垂直化 6
1.1.4 为什么需要实现服务化架构 8
1.1.5 服务拆分粒度之微服务 10
1.2 系统服务化需求 11
1.2.1 服务化与RPC协议 11
1.2.2 使用阿里分布式服务框架Dubbo实现服务化 12
1.2.3 警惕Dubbo因超时和重试引起的系统雪崩 16
1.2.4 服务治理方案 18
1.2.5 关于服务化后的分布式事务问题 20
1.3 分布式调用跟踪系统需求 21
1.3.1 Google的Dapper论文简介 22
1.3.2 基于Dubbo实现分布式调用跟踪系统方案 25
1.3.3 采样率方案 35
1.4 本章小结 37
第2章大流量限流/消峰案例 38
2.1 分布式系统为什么需要进行流量管制 39
2.2 限流的具体方案 42
2.2.1 常见的限流算法 43
2.2.2 使用Google的Guava实现平均速率限流 45
2.2.3 使用Nginx实现接入层限流 48
2.2.4 使用计数器算法实现商品抢购限流 49
2.3 基于时间分片的消峰方案 51
2.3.1 活动分时段进行实现消峰 52
2.3.2 通过答题验证实现消峰 52
2.4 异步调用需求 53
2.4.1 使用MQ实现系统之间的解耦 54
2.4.2 使用Apache开源的ActiveMQ实现异步调用 55
2.4.3 使用阿里开源的RocketMQ实现互联网场景下的流量消峰 61
2.4.4 基于MQ方案实现流量消峰的一些典型案例 72
2.5 本章小结 75
第3章分布式配置管理服务案例 76
3.1 本地配置 77
3.1.1 将配置信息耦合在业务代码中 77
3.1.2 将配置信息配置在配置文件中 79
3.2 集中式资源配置需求 82
3.2.1 分布式一致性协调服务ZooKeeper简介 83
3.2.2 ZooKeeper的下载与集群安装 84
3.2.3 ZooKeeper的基本使用技巧 86
3.2.4 基于ZooKeeper实现分布式配置管理平台方案 87
3.2.5 从配置中心获取Spring的Bean定义实现Bean动态注册 93
3.2.6 容灾方案 95
3.2.7 使用淘宝Diamond实现分布式配置管理服务 96
3.2.8 Diamond与ZooKeeper的细节差异 101
3.2.9 使用百度Disconf实现分布式配置管理服务 102
3.3 本章小结 110
第4章大促场景下热点数据的读/写优化案例 111
4.1 缓存技术简介 112
4.1.1 使用Ehcache实现数据缓存 114
4.1.2 LocalCache存在的弊端 116
4.1.3 神秘的off-heap技术 117
4.2 高性能分布式缓存Redis简介 120
4.2.1 使用Jedis客户端操作Redis 121
4.2.2 使用Redis集群实现数据水平化存储 122
4.3 同一热卖商品高并发读需求 124
4.3.1 Redis集群多写多读方案 125
4.3.2 保障多写时的数据一致性 126
4.3.3 LocalCache结合Redis集群的多级Cache方案 128
4.3.4 实时热点自动发现方案 130
4.4 同一热卖商品高并发写需求 132
4.4.1 InnoDB行锁引起数据库TPS下降 132
4.4.2 在Redis中扣减热卖商品库存方案 134
4.4.3 热卖商品库存扣减优化方案 138
4.4.4 控制单机并发写流量方案 141
4.4.5 使用阿里开源的AliSQL数据库提升秒杀场景性能 142
4.5 本章小结 148
第5章数据库分库分表案例 149
5.1 关系型数据库的架构演变 150
5.1.1 数据库读写分离 150
5.1.2 数据库垂直分库 151
5.1.3 数据库水平分库与水平分表 152
5.1.4 MySQL Sharding与MySQL Cluster的区别 153
5.2 Sharding中间件 154
5.2.1 常见的 Sharding中间件对比 155
5.2.2 Shark简介 156
5.2.3 Shark的架构模型 157
5.2.4 使用Shark实现分库分表后的数据路由任务 159
5.2.5 分库分表后所带来的影响 166
5.2.6 多机SequenceID解决方案 167
5.2.7 使用Solr满足多维度的复杂条件查询 170
5.2.8 关于分布式事务 172
5.3 数据库的HA方案 173
5.3.1 基于配置中心实现主从切换 174
5.3.2 基于Keepalived实现主从切换 176
5.3.3 保障主从切换过程中的数据一致性 179
5.4 订单业务冗余表需求 180
5.4.1 冗余表的实现方案 181
5.4.2 保障冗余表的数据一致性 183
5.5 本章小结 186
后记 187

全部展开

读者评论

4.4.2节中，请问一下，既然redis是单线程的架构，使用decr判断返回值的方式就可以避免超卖了，为什么还需要使用分布式锁？

jokerChendi发表于 2018/5/9 0:19:12
您好，请问，第五章讲的分库为什么不在框架上做？记得也有mybatis-shard之类的东东啊，谢谢

ycd发表于 2017/10/26 7:03:16