起因是前两天在掘金刷到这个

后端架构师技术图谱

一个非常详细的java后端技术集合，里面就提到了这本书，这本书暂时还没出版好像？

在ws3cshcool可以读到https://www.w3cschool.cn/architectroad/
初看就感觉出来是本对后端架构技术概况的很好的书。作者文笔清晰，技术精湛。我就边读边做笔记了。

互联网架构设计如何进行容量评估：

【步骤一：评估总访问量】

->询问业务、产品、运营

【步骤二：评估平均访问量QPS】

->除以时间，一天算4w秒

【步骤三：评估高峰QPS】

->根据业务曲线图来

【步骤四：评估系统、单机极限QPS】

->压测很重要

【步骤五：根据线上冗余度回答两个问题】

-> 估计冗余度与线上冗余度差值

N核服务器，通过执行业务的单线程分析出本地计算时间为x，等待时间为y，则工作线程数（线程池线程数）设置为 N*(x+y)/x，能让CPU的利用率最大化。

文章写了很长，最后做一个简单总结，面对100亿数据量，1万列属性，10万吞吐量的业务需求，58同城的经验，是采用了元数据服务、属性服务、搜索服务来解决的。

tcp-server 不是很懂

如何保证高可用？

客户配置多个tcp-server的域名。

如何防止DNS劫持，以及加速？

IP直通车，客户端配置多个tcp-server的IP。

如何保证扩展性？

服务端提供get-tcp-ip接口，向client屏屏蔽负载均衡策略，并实施便捷扩容。

对比“全局配置”与“配置中心”的架构图，会发现配置由静态的文件升级为动态的服务：
1）整个配置中心子系统由zk、conf-center服务，DB配置存储与，conf-web配置后台组成

2.4如何提高数据库的扩展性？原来用hash的方式路由，分为2个库，数据量还是太大，要分为3个库，势必需要进行数据迁移，58同城有一个很帅气的“数据库秒级扩容”方案。扩容步骤：第一步，将一个主库提升

第二步，修改配置，2库变4库（原来MOD2，现在配置修改后MOD4）扩容完成

为了解决主从数据库读取旧数据的问题，常用的方案有四种：（1）半同步复制（2）强制读主（3）数据库中间件（4）缓存记录写key

3如果有了数据库中间件，所有的数据库请求都走中间件。既然数据库中间件的成本比较高，有没有更低成本的方案来记录某一个库的某一个key上发生了写请求呢？4很容易想到使用缓存，当写请求发生的时候：

从mysql并行复制缩短主从同步时延的思想可以看到，架构的思路是相同的：

（1）多线程是一种常见的缩短执行时间的方法

（2）多线程并发分派任务时必须保证幂等性：mysql的演进思路，提供了“按照库幂等”，“按照commit_id幂等”两种方式，思路大伙可以借鉴

另，mysql在并行复制上的逐步优化演进：

mysql5.5 -> 不支持并行复制，对大伙的启示：升级mysql吧

mysql5.6 -> 按照库并行复制，对大伙的启示：使用“多库”架构吧

mysql5.7 -> 按照GTID并行复制

今天介绍了解决“跨N库分页”这一难题的四种方法(https://www.w3cschool.cn/architectroad/architectroad-cross-database-paging.html)：

方法一：全局视野法

（1）将order by time offset X limit Y，改写成order by time offset 0 limit X+Y

（2）服务层对得到的N*(X+Y)条数据进行内存排序，内存排序后再取偏移量X后的Y条记录

这种方法随着翻页的进行，性能越来越低。

方法二：业务折衷法-禁止跳页查询

（1）用正常的方法取得第一页数据，并得到第一页记录的time_max

（2）每次翻页，将order by time offset X limit Y，改写成order by time where time>$time_max limit Y

以保证每次只返回一页数据，性能为常量。

方法三：业务折衷法-允许模糊数据

（1）将order by time offset X limit Y，改写成order by time offset X/N limit Y/N

方法四：二次查询法

（1）将order by time offset X limit Y，改写成order by time offset X/N limit Y

（2）找到最小值time_min

（3）between二次查询，order by time between $time_min and $time_i_max

（4）设置虚拟time_min，找到time_min在各个分库的offset，从而得到time_min在全局的offset

（5）得到了time_min在全局的offset，自然得到了全局的offset X limit Y

所谓序列化（Serialization），就是将“对象”形态的数据转化为“连续空间二进制字节流”形态数据的过程，以方便存储与传输。这个过程的逆过程叫做反序列化。

不管使用成熟协议xml/json，还是自定义二进制协议来序列化对象，序列化协议设计时要考虑哪些因素呢？

（1）解析效率：这个应该是序列化协议应该首要考虑的因素，像xml/json解析起来比较耗时，需要解析doom树，二进制自定义协议解析起来效率就很高

（2）压缩率，传输有效性：同样一个对象，xml/json传输起来有大量的xml标签，信息有效性低，二进制自定义协议占用的空间相对来说就小多了

（3）扩展性与兼容性：是否能够方便的增加字段，增加字段后旧版客户端是否需要强制升级，都是需要考虑的问题，xml/json和上面的二进制协议都能够方便的扩展

（4）可读性与可调试性：这个很好理解，xml/json的可读性就比二进制协议好很多

（5）跨语言：上面的两个协议都是跨语言的，有些序列化协议是与开发语言紧密相关的，例如dubbo的序列化协议就只能支持Java的RPC调用

（6）通用性：xml/json非常通用，都有很好的第三方解析库，各个语言解析起来都十分方便，上面自定义的二进制协议虽然能够跨语言，但每个语言都要写一个简易的协议客户端

（7）欢迎大家补充…

升级RPC-client内部的连接池，在service连接选取上做微小改动，就能够实现“id串行化”，实现不同类型的业务gid/uid等的串行化、序列号需求（这下查找日志就方便了，一个群gid/用户uid的日志只需去一台机器grep啦）。