A. 干货来了，分库分表的实战案例分享
问题现状
某系统， 订单单表早就已经突破200G ，由于查询维度较多，即使加了 两个从库，优化索引 等优化手段也无济于事。因为数据库达到瓶颈，应用只能通过 限速、异步队列等对其进行保护， 因此进行分库分表的尝试 。
整体思路
按照商户ID进行分库，用户ID进行分表，同时通过数据同步等方式，把数据同步到一个运营库， 同时满足C端用户、B端商户、客服、运营等的需求。最终，通过 新老系统双写 逐渐从老库过渡到新库，完成业务的切换。
切分策略
1. 查询切分
将ID和库的Mapping关系记录在一个单独瞎仿的库中，但是这样 引入额外的服务器来维护这个Mapping关系 。
2. 范围切分
按照时间区间或ID区间来切分。但是 针对于某些大商户来说，还是解决不了性能瓶颈的问题 。
3. Hash切分（最终方案）
我们分库分表的方案是16*16的。
商户Id后四位mod 16 分16个库，拦蚂 UserId后四位Mod 16 将每个库分为16个表，共计分为256张表。
线上部署情况为 4个集群 ，每个集群4个库（ 1主3从 ）。
场景一：数据库性能达到瓶颈：扩大数据库的集群数量，从16个数据库变成32个数据库。
场景二：单表容量达到瓶颈：扩大分简神埋表的数量，从16切分变成32切分。
唯一ID方案
1. 利用数据库自增ID(单点风险、单机性能瓶颈)
2. 利用数据库集群并设置相应的步长（ 需要单独的数据库集群 ）
3. Twitter Snowflake( 需要独立的集群以及ZK )
4. 采用了带有业务属性的方案：（时间戳+商户ID+用户ID+随机数）
其他问题
数据迁移
第一阶段
第二阶段
第三阶段
总结
B. newsql和nosql的区别和联系
TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。
TiDB 具备如下特性：
高度兼容 MySQL
大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
水平弹性扩展
通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
分布式事务
TiDB 100% 支持标准的 ACID 事务。
真正金融级高可用
相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
一站式 HTAP 解决方案
TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。
云原生 SQL 数据库
TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，配合TiDB Operator 项目可实现自动化运维，使部署、配置和维护变得十分简单。
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过TiSpark 项目来完成。
TiDB 对业务没有任何侵入性，能优雅地替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大地提升研发的生产力。
C. 超详细MySQL数据库优化
数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷.
1. 优化一览图
2. 优化
笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置.
2.1 软优化
2.1.1 查询语句优化
1.首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息.
2.例:
显示:
其中会显示索引和查询数据读取数据条数等信息.
2.1.2 优化子查询
在MySQL中,尽量使用JOIN来代替子查询.因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高.
2.1.3 使用索引
索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:
2.1.4 分解表
对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,
2.1.5 中间表
对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时.
2.1.6 增加冗余字段
类似于创建中间表,增加冗余也是为了减少连接查询.
2.1.7 分析表,,检查表,优化表
分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费.
1. 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;
2. 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]
option 只对MyISAM有效,共五个参数值:
3. 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志.,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁.
2.2 硬优化
2.2.1 硬件三件套
1.配置多核心和频率高的cpu,多核心可以执行多个线程.
2.配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.
3.配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.
2.2.2 优化数据库参数
优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能.MySQL服务的配置参数都在my.cnf或my.ini,下面列出性能影响较大的几个参数.
2.2.3 分库分表
因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。另外一个，压力过大把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。
2.2.4 缓存集群
如果用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。如果你就是简单的不停的加机器，其实是不对的。所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
一个完整而复杂的高并发系统架构中，一定会包含：各种复杂的自研基础架构系统。各种精妙的架构设计.因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了.
D. 数据库集群、负载均衡、主从配置、动静(读写)分离、分表分库是dba还是运维还是开发干的活，我一个开
谁懂迅猛，谁去做
~~~~~
想用、铅戚没专门的亩激桥人，就得自己弄
~
E. php怎么处理高并发
以下内容转载自徐汉彬大牛的博客亿级Web系统搭建——单机到分布式集群
当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段，我们会遇到不同的问题，通过搭建不同的服务和架构来解决。
Web负载均衡
Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。
负载均衡的策略有很多，我们从简单的讲起哈。
1.HTTP重定向
当用户发来请求的时候，Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url，然后浏览器再继续请求这个新url，实际上就是页面重定向。通过重定向，来达到“负载均衡”的目标。例如，我们在下载PHP源码包的时候，点击下载链接时，为了解决不同国家和地域下载速度的问题，它会返回一个离我们近的下载地址。重定向的HTTP返回码是302
这个重定向非常容易实现，并且可以自定义各种策略。但是，它在大规模访问量下，性能不佳。而且，给用户的体验也不好，实际请求发生重定向，增加了网络延时。
2. 反向代理负载均衡
反向代理服务的核心工作主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层（应用层），也就是网络七层结构中的第七层，因此也被称为“七层负载均衡”。可以做反向代理的软件很多，比较常见的一种是Nginx。
Nginx是一种非常灵活的反向代理软件，可以自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求，无法保证一定分配到相同的Web机器上，会导致无法找到session的问题。
解决方案主要有两种：
1.配置反向代理的转发规则，让同一个用户的请求一定落到同一台机器上（通过分析cookie），复杂的转发规则将会消耗更多的CPU，也增加了代理服务器的负担。
2.将session这类的信息，专门用某个独立服务来存储，例如redis/memchache，这个方案是比较推荐的。
反向代理服务，也是可以开启缓存的，如果开启了，会增加反向代理的负担，需要谨慎使用。这种负载均衡策略实现和部署非常简单，而且性能表现也比较好。但是，它有“单点故障”的问题，如果挂了，会带来很多的麻烦。而且，到了后期Web服务器继续增加，它本身可能成为系统的瓶颈。
3. IP负载均衡
IP负载均衡服务是工作在网络层（修改IP）和传输层（修改端口，第四层），比起工作在应用层（第七层）性能要高出非常多。原理是，他是对IP层的数据包的IP地址和端口信息进行修改，达到负载均衡的目的。这种方式，也被称为“四层负载均衡”。常见的负载均衡方式，是LVS（Linux Virtual Server，Linux虚拟服务），通过IPVS（IP Virtual Server，IP虚拟服务）来实现。
在负载均衡服务器收到客户端的IP包的时候，会修改IP包的目标IP地址或端口，然后原封不动地投递到内部网络中，数据包会流入到实际Web服务器。实际服务器处理完成后，又会将数据包投递回给负载均衡服务器，它再修改目标IP地址为用户IP地址，最终回到客户端。
上述的方式叫LVS-NAT，除此之外，还有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之间都属于LVS的方式，但是有一定的区别，篇幅问题，不赘叙。
IP负载均衡的性能要高出Nginx的反向代理很多，它只处理到传输层为止的数据包，并不做进一步的组包，然后直接转发给实际服务器。不过，它的配置和搭建比较复杂。
4. DNS负载均衡
DNS（Domain Name System）负责域名解析的服务，域名url实际上是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此，DNS也就可以作为负载均衡服务。
这种负载均衡策略，配置简单，性能极佳。但是，不能自由定义规则，而且，变更被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。
5. DNS/GSLB负载均衡
我们常用的CDN（Content Delivery Network，内容分发网络）实现方式，其实就是在同一个域名映射为多IP的基础上更进一步，通过GSLB（Global Server Load Balance，全局负载均衡）按照指定规则映射域名的IP。一般情况下都是按照地理位置，将离用户近的IP返回给用户，减少网络传输中的路由节点之间的跳跃消耗。
“向上寻找”，实际过程是LDNS（Local DNS）先向根域名服务（Root Name Server）获取到顶级根的Name Server（例如.com的），然后得到指定域名的授权DNS，然后再获得实际服务器IP。
CDN在Web系统中，一般情况下是用来解决大小较大的静态资源（html/Js/Css/图片等）的加载问题，让这些比较依赖网络下载的内容，尽可能离用户更近，提升用户体验。
例如，我访问了一张imgcache.gtimg.cn上的图片（腾讯的自建CDN，不使用qq.com域名的原因是防止http请求的时候，带上了多余的cookie信息），我获得的IP是183.60.217.90。
这种方式，和前面的DNS负载均衡一样，不仅性能极佳，而且支持配置多种策略。但是，搭建和维护成本非常高。互联网一线公司，会自建CDN服务，中小型公司一般使用第三方提供的CDN。
Web系统的缓存机制的建立和优化
刚刚我们讲完了Web系统的外部网络环境，现在我们开始关注我们Web系统自身的性能问题。我们的Web站点随着访问量的上升，会遇到很多的挑战，解决这些问题不仅仅是扩容机器这么简单，建立和使用合适的缓存机制才是根本。
最开始，我们的Web系统架构可能是这样的，每个环节，都可能只有1台机器。
我们从最根本的数据存储开始看哈。
一、 MySQL数据库内部缓存使用
MySQL的缓存机制，就从先从MySQL内部开始，下面的内容将以最常见的InnoDB存储引擎为主。
1. 建立恰当的索引
最简单的是建立索引，索引在表数据比较大的时候，起到快速检索数据的作用，但是成本也是有的。首先，占用了一定的磁盘空间，其中组合索引最突出，使用需要谨慎，它产生的索引甚至会比源数据更大。其次，建立索引之后的数据insert/update/delete等操作，因为需要更新原来的索引，耗时会增加。当然，实际上我们的系统从总体来说，是以select查询操作居多，因此，索引的使用仍然对系统性能有大幅提升的作用。
2. 数据库连接线程池缓存
如果，每一个数据库操作请求都需要创建和销毁连接的话，对数据库来说，无疑也是一种巨大的开销。为了减少这类型的开销，可以在MySQL中配置thread_cache_size来表示保留多少线程用于复用。线程不够的时候，再创建，空闲过多的时候，则销毁。
其实，还有更为激进一点的做法，使用pconnect（数据库长连接），线程一旦创建在很长时间内都保持着。但是，在访问量比较大，机器比较多的情况下，这种用法很可能会导致“数据库连接数耗尽”，因为建立连接并不回收，最终达到数据库的max_connections（最大连接数）。因此，长连接的用法通常需要在CGI和MySQL之间实现一个“连接池”服务，控制CGI机器“盲目”创建连接数。
建立数据库连接池服务，有很多实现的方式，PHP的话，我推荐使用swoole（PHP的一个网络通讯拓展）来实现。
3. Innodb缓存设置（innodb_buffer_pool_size）
innodb_buffer_pool_size这是个用来保存索引和数据的内存缓存区，如果机器是MySQL独占的机器，一般推荐为机器物理内存的80%。在取表数据的场景中，它可以减少磁盘IO。一般来说，这个值设置越大，cache命中率会越高。
4. 分库/分表/分区。
MySQL数据库表一般承受数据量在百万级别，再往上增长，各项性能将会出现大幅度下降，因此，当我们预见数据量会超过这个量级的时候，建议进行分库/分表/分区等操作。最好的做法，是服务在搭建之初就设计为分库分表的存储模式，从根本上杜绝中后期的风险。不过，会牺牲一些便利性，例如列表式的查询，同时，也增加了维护的复杂度。不过，到了数据量千万级别或者以上的时候，我们会发现，它们都是值得的。
二、 MySQL数据库多台服务搭建
1台MySQL机器，实际上是高风险的单点，因为如果它挂了，我们Web服务就不可用了。而且，随着Web系统访问量继续增加，终于有一天，我们发现1台MySQL服务器无法支撑下去，我们开始需要使用更多的MySQL机器。当引入多台MySQL机器的时候，很多新的问题又将产生。
1. 建立MySQL主从，从库作为备份
这种做法纯粹为了解决“单点故障”的问题，在主库出故障的时候，切换到从库。不过，这种做法实际上有点浪费资源，因为从库实际上被闲着了。
2. MySQL读写分离，主库写，从库读。
两台数据库做读写分离，主库负责写入类的操作，从库负责读的操作。并且，如果主库发生故障，仍然不影响读的操作，同时也可以将全部读写都临时切换到从库中（需要注意流量，可能会因为流量过大，把从库也拖垮）。
3. 主主互备。
两台MySQL之间互为彼此的从库，同时又是主库。这种方案，既做到了访问量的压力分流，同时也解决了“单点故障”问题。任何一台故障，都还有另外一套可供使用的服务。
不过，这种方案，只能用在两台机器的场景。如果业务拓展还是很快的话，可以选择将业务分离，建立多个主主互备。
三、 MySQL数据库机器之间的数据同步
每当我们解决一个问题，新的问题必然诞生在旧的解决方案上。当我们有多台MySQL，在业务高峰期，很可能出现两个库之间的数据有延迟的场景。并且，网络和机器负载等，也会影响数据同步的延迟。我们曾经遇到过，在日访问量接近1亿的特殊场景下，出现，从库数据需要很多天才能同步追上主库的数据。这种场景下，从库基本失去效用了。
于是，解决同步问题，就是我们下一步需要关注的点。
1. MySQL自带多线程同步
MySQL5.6开始支持主库和从库数据同步，走多线程。但是，限制也是比较明显的，只能以库为单位。MySQL数据同步是通过binlog日志，主库写入到binlog日志的操作，是具有顺序的，尤其当SQL操作中含有对于表结构的修改等操作，对于后续的SQL语句操作是有影响的。因此，从库同步数据，必须走单进程。
2. 自己实现解析binlog，多线程写入。
以数据库的表为单位，解析binlog多张表同时做数据同步。这样做的话，的确能够加快数据同步的效率，但是，如果表和表之间存在结构关系或者数据依赖的话，则同样存在写入顺序的问题。这种方式，可用于一些比较稳定并且相对独立的数据表。
国内一线互联网公司，大部分都是通过这种方式，来加快数据同步效率。还有更为激进的做法，是直接解析binlog，忽略以表为单位，直接写入。但是这种做法，实现复杂，使用范围就更受到限制，只能用于一些场景特殊的数据库中（没有表结构变更，表和表之间没有数据依赖等特殊表）。
四、 在Web服务器和数据库之间建立缓存
实际上，解决大访问量的问题，不能仅仅着眼于数据库层面。根据“二八定律”，80%的请求只关注在20%的热点数据上。因此，我们应该建立Web服务器和数据库之间的缓存机制。这种机制，可以用磁盘作为缓存，也可以用内存缓存的方式。通过它们，将大部分的热点数据查询，阻挡在数据库之前。
1. 页面静态化
用户访问网站的某个页面，页面上的大部分内容在很长一段时间内，可能都是没有变化的。例如一篇新闻报道，一旦发布几乎是不会修改内容的。这样的话，通过CGI生成的静态html页面缓存到Web服务器的磁盘本地。除了第一次，是通过动态CGI查询数据库获取之外，之后都直接将本地磁盘文件返回给用户。
在Web系统规模比较小的时候，这种做法看似完美。但是，一旦Web系统规模变大，例如当我有100台的Web服务器的时候。那样这些磁盘文件，将会有100份，这个是资源浪费，也不好维护。这个时候有人会想，可以集中一台服务器存起来，呵呵，不如看看下面一种缓存方式吧，它就是这样做的。
2. 单台内存缓存
通过页面静态化的例子中，我们可以知道将“缓存”搭建在Web机器本机是不好维护的，会带来更多问题（实际上，通过PHP的apc拓展，可通过Key/value操作Web服务器的本机内存）。因此，我们选择搭建的内存缓存服务，也必须是一个独立的服务。
内存缓存的选择，主要有redis/memcache。从性能上说，两者差别不大，从功能丰富程度上说，Redis更胜一筹。
3. 内存缓存集群
当我们搭建单台内存缓存完毕，我们又会面临单点故障的问题，因此，我们必须将它变成一个集群。简单的做法，是给他增加一个slave作为备份机器。但是，如果请求量真的很多，我们发现cache命中率不高，需要更多的机器内存呢？因此，我们更建议将它配置成一个集群。例如，类似redis cluster。
Redis cluster集群内的Redis互为多组主从，同时每个节点都可以接受请求，在拓展集群的时候比较方便。客户端可以向任意一个节点发送请求，如果是它的“负责”的内容，则直接返回内容。否则，查找实际负责Redis节点，然后将地址告知客户端，客户端重新请求。
对于使用缓存服务的客户端来说，这一切是透明的。
内存缓存服务在切换的时候，是有一定风险的。从A集群切换到B集群的过程中，必须保证B集群提前做好“预热”（B集群的内存中的热点数据，应该尽量与A集群相同，否则，切换的一瞬间大量请求内容，在B集群的内存缓存中查找不到，流量直接冲击后端的数据库服务，很可能导致数据库宕机）。
4. 减少数据库“写”
上面的机制，都实现减少数据库的“读”的操作，但是，写的操作也是一个大的压力。写的操作，虽然无法减少，但是可以通过合并请求，来起到减轻压力的效果。这个时候，我们就需要在内存缓存集群和数据库集群之间，建立一个修改同步机制。
先将修改请求生效在cache中，让外界查询显示正常，然后将这些sql修改放入到一个队列中存储起来，队列满或者每隔一段时间，合并为一个请求到数据库中更新数据库。
除了上述通过改变系统架构的方式提升写的性能外，MySQL本身也可以通过配置参数innodb_flush_log_at_trx_commit来调整写入磁盘的策略。如果机器成本允许，从硬件层面解决问题，可以选择老一点的RAID（Rendant Arrays of independent Disks，磁盘列阵）或者比较新的SSD（Solid State Drives，固态硬盘）。
5. NoSQL存储
不管数据库的读还是写，当流量再进一步上涨，终会达到“人力有穷时”的场景。继续加机器的成本比较高，并且不一定可以真正解决问题的时候。这个时候，部分核心数据，就可以考虑使用NoSQL的数据库。NoSQL存储，大部分都是采用key-value的方式，这里比较推荐使用上面介绍过Redis，Redis本身是一个内存cache，同时也可以当做一个存储来使用，让它直接将数据落地到磁盘。
这样的话，我们就将数据库中某些被频繁读写的数据，分离出来，放在我们新搭建的Redis存储集群中，又进一步减轻原来MySQL数据库的压力，同时因为Redis本身是个内存级别的Cache，读写的性能都会大幅度提升。
国内一线互联网公司，架构上采用的解决方案很多是类似于上述方案，不过，使用的cache服务却不一定是Redis，他们会有更丰富的其他选择，甚至根据自身业务特点开发出自己的NoSQL服务。
6. 空节点查询问题
当我们搭建完前面所说的全部服务，认为Web系统已经很强的时候。我们还是那句话，新的问题还是会来的。空节点查询，是指那些数据库中根本不存在的数据请求。例如，我请求查询一个不存在人员信息，系统会从各级缓存逐级查找，最后查到到数据库本身，然后才得出查找不到的结论，返回给前端。因为各级cache对它无效，这个请求是非常消耗系统资源的，而如果大量的空节点查询，是可以冲击到系统服务的。
在我曾经的工作经历中，曾深受其害。因此，为了维护Web系统的稳定性，设计适当的空节点过滤机制，非常有必要。
我们当时采用的方式，就是设计一张简单的记录映射表。将存在的记录存储起来，放入到一台内存cache中，这样的话，如果还有空节点查询，则在缓存这一层就被阻挡了。
异地部署（地理分布式）
完成了上述架构建设之后，我们的系统是否就已经足够强大了呢？答案当然是否定的哈，优化是无极限的。Web系统虽然表面上看，似乎比较强大了，但是给予用户的体验却不一定是最好的。因为东北的同学，访问深圳的一个网站服务，他还是会感到一些网络距离上的慢。这个时候，我们就需要做异地部署，让Web系统离用户更近。
一、 核心集中与节点分散
有玩过大型网游的同学都会知道，网游是有很多个区的，一般都是按照地域来分，例如广东专区，北京专区。如果一个在广东的玩家，去北京专区玩，那么他会感觉明显比在广东专区卡。实际上，这些大区的名称就已经说明了，它的服务器所在地，所以，广东的玩家去连接地处北京的服务器，网络当然会比较慢。
当一个系统和服务足够大的时候，就必须开始考虑异地部署的问题了。让你的服务，尽可能离用户更近。我们前面已经提到了Web的静态资源，可以存放在CDN上，然后通过DNS/GSLB的方式，让静态资源的分散“全国各地”。但是，CDN只解决的静态资源的问题，没有解决后端庞大的系统服务还只集中在某个固定城市的问题。
这个时候，异地部署就开始了。异地部署一般遵循：核心集中，节点分散。
·核心集中：实际部署过程中，总有一部分的数据和服务存在不可部署多套，或者部署多套成本巨大。而对于这些服务和数据，就仍然维持一套，而部署地点选择一个地域比较中心的地方，通过网络内部专线来和各个节点通讯。
·节点分散：将一些服务部署为多套，分布在各个城市节点，让用户请求尽可能选择近的节点访问服务。
例如，我们选择在上海部署为核心节点，北京，深圳，武汉，上海为分散节点（上海自己本身也是一个分散节点）。我们的服务架构如图：
需要补充一下的是，上图中上海节点和核心节点是同处于一个机房的，其他分散节点各自独立机房。
国内有很多大型网游，都是大致遵循上述架构。它们会把数据量不大的用户核心账号等放在核心节点，而大部分的网游数据，例如装备、任务等数据和服务放在地区节点里。当然，核心节点和地域节点之间，也有缓存机制。
二、 节点容灾和过载保护
节点容灾是指，某个节点如果发生故障时，我们需要建立一个机制去保证服务仍然可用。毫无疑问，这里比较常见的容灾方式，是切换到附近城市节点。假如系统的天津节点发生故障，那么我们就将网络流量切换到附近的北京节点上。考虑到负载均衡，可能需要同时将流量切换到附近的几个地域节点。另一方面，核心节点自身也是需要自己做好容灾和备份的，核心节点一旦故障，就会影响全国服务。
过载保护，指的是一个节点已经达到最大容量，无法继续接接受更多请求了，系统必须有一个保护的机制。一个服务已经满负载，还继续接受新的请求，结果很可能就是宕机，影响整个节点的服务，为了至少保障大部分用户的正常使用，过载保护是必要的。
解决过载保护，一般2个方向：
·拒绝服务，检测到满负载之后，就不再接受新的连接请求。例如网游登入中的排队。
·分流到其他节点。这种的话，系统实现更为复杂，又涉及到负载均衡的问题。
小结
Web系统会随着访问规模的增长，渐渐地从1台服务器可以满足需求，一直成长为“庞然大物”的大集群。而这个Web系统变大的过程，实际上就是我们解决问题的过程。在不同的阶段，解决不同的问题，而新的问题又诞生在旧的解决方案之上。
系统的优化是没有极限的，软件和系统架构也一直在快速发展，新的方案解决了老的问题，同时也带来新的挑战。
F. 架构师的技术升级之路
这篇文章更多的是从沟通角度分析架构师的升级之道。但我们知道，架构师更多是靠技术拿高薪。
在本文里，我将列些我见到的技术架构平时需要解决的问题，有技术的，也有沟通协调方面的，以这些实实在在的案例，来列举些技术架构需要具备的技能，以此来分析下高级开发如何更高效地升级到技术架构。好了，开场白结束，正文开始。
1 技术本身不产生价值，业务才会，论技术和业务的整合
一般会把架构分为技术架构和业务架构，这里我无意对比这两类的优劣，但我只想说，在公司里，是靠业务价值创造盈利点的，所以技术，比如消息运桥队列，内存优化，以及分库分表数据库集群等，只有嵌入到业务里，才能通过提升业务的可扩展性或性能，从而产生价值。
上述似乎是废话，但恰恰是架构师工作的难点，大家可以想象一下，比如通过MyCat搭建个分库分表架构不难，甚至把分库分表组件通过负载均衡搭建成集群也不难，这些网上都有现成的案例。但如何要凯知在当前的业务系统里实现分库分表，难度就不小了。具体来讲，因为业务系统里或许有冗余数据，而且有各类带join, group by等的查询语句，如何在分库分表系统里兼容这些 历史 问题，而且在上线新分库系统后迁移 历史 数据，又如，在产线切换到分库分表时，万一有问题如何回退，这些绝非是知道些Demo案例的高级开发能解决的问题。
所以在技术和业务方面，我自己的感受是（包括我见到的和听到的） ：只有接触到业务了，才能用技术解决实际问题，才能更了解这个技术用起来的各类坑，像刚才提到的分库分表是这样，其它的诸如日志组件，消息队列组件都这样。通过下面部分给出的架构师平时要解决的实际问题的讲述，大家能更深刻地体会到这点。
2 资深架构师平时要解决的问题
如下的问题均是来源于实际，出于项目保密的原则，本人隐去了关键性的业务描述，但大家都能看懂，并能感受到架构师平时要解决问题的难度。
问题一，A公司有财务管理人事管理等10个左右的项目，它们在产线上，需要标准化管理，比如用同一个Maven仓库，不论功能业务如何，得用同一套配置管理服务，用同一套日志管理和分析组件，还得用同一套大数据组件来根据不同的业务维度来分析数据。
如果是重新搭建一套系统，这个难度也不小，更何况，对资深架构师的要求是，在 历史 项目的技术上做标准化管理，否则每个项目各管各的，维护成本大不算，不同项目间的库还很容易产生冲突。架构师要在保持业务稳定的前提下实现这点，大家可以考虑下难度。
问题二，随着B公司业务量的上升，数据库里的数据达到了T级，所以需要通过分库分表来实现优化。这本身不难，但如何在升级的过程中保持业务的稳定？不能说上个功能点，关键业务就挂了，而且，万一上线后出现问题，得提供应急的回退方案。
问题三，C公司是个创业型公司，刚开始的时候，通过SSM外加Oracle，能满足大多数的业务需求，但随着业务量的提升，需盯悄消要资深架构在短时间里实现针对高并发和大数据的方案，比如并发量高了，系统至少不能垮，而且针对每笔订单，处理可以稍作延迟，但不能丢数据。
问题四，D公司需要在linux上搭建一套和产线一样的测试环境，在平时的开发过程中，各业务组可以通过工具，在测试环境上部署或回退本项目的组件，这里，不仅要搭建测试环境，更要通过jenkins等工具给各业务组搭建一套能便捷部署系统的工具。
除了上述的问题之外，资深架构更像一个救火队员，比如在公司的业务体系里，任何一个团队报出的和架构相关的问题，比如调消息队列有延迟，调分库分表时报内存OOM异常了，或者因Dubbo底层而导致的延迟或OOM，资深架构得能亲自或带领手下解决具体的问题。
3 和高级开发相比，资深架构一定得精通的技能（或素质）
其实高级开发和资深架构在需要掌握的技能方面，并没太大的差别，具体而言，能帮助实现性能优化的分布式组件和数据库组件（或者叫中间件）也就这么多，linux下的操作命令也就这么些，一些系统管理的工具，比如Maven，Jenkins，ant等的用法也不难。但和高级开发相比，资深架构的差别在于如下几点。
1 资深架构解决的问题种类和数量要比高级开发多很多，所谓神枪手得靠子弹喂出来，有些问题，比如针对Kafka消息中间件的问题，资深架构一看日志就知道该怎么改，或者一看log4j错误信息就知道和其它哪些类有冲突了，又如，在搭建线程池时遇到了OOM问题，资深架构估计也能通过简单地看日志，也能快速定位问题所在。
也就是说，资深架构已经积累了很多处理问题的经验，遇到一般问题时，无需再通过比较耗时的debug看问题根源，往往在脑子里已经存储了大量可能会导致问题的原因，再通过查看关键日志即可定位到具体的代码点，然后就能很快地给出解决方案。
2 在给出解决方案时，比如要上个分布式redis集群，或者上个消息中间件，对高级开发而言，往往会有很多试错的时间，比如上线后有某些功能点没调通，得通过Debug或查日志来逐一解决问题，或上线某个基于python的大数据分析系统后，虽然能满足基本的功能，但在某个场景（比如写日志线程并发量太多）里，可能会导致OOM异常。
而对资深架构来说，往往之前已经做过同类事情，所以能避免很多坑（少了很多试错成本和时间），而且由于对底层代码比较熟悉，所以哪怕出现比较疑难的问题（比如不能稳定重现），资深架构能通过看日志很快定位到具体的底层类，（而高级开发一般对此就束手无策了）。相比之下，资深架构的中流砥柱效应就能体现出来。
3 资深架构一般具有对各组件的差别非常了解，比如做分布式队列，该先用Kafka还是rabbitMQ，或者搭建数据库集群时，该用MySQL里的哪种引擎。
这样，在选型时，由于知道了各种方案的优缺点，所以能知道哪类方案更适合本业务系统，或者说，通过重写哪类组件的底层代码，能很快地搭建起满足本系统的中间件组件。这点，高级开发未必能做到。
总结一下，资深架构得对关键组件的底层非常了解，并且精通针对某些组件（比如消息组件，分库组件）的实施和排查问题的能力，此外，资深架构的基本功也得非常扎实。
1 debug能力就不用说了，得能熟练地通过linux命令，从各类日志中发现并解决问题。
2 无需了解所有组件的底层代码（这太难了，也做不到），但需要了解一些常用组件的关键底层实现（比如Spring IOC或常用中间件） 方式，更得具备到组件内部jar里debug排查问题的能力。
3 学习能力更不说了，和高级开发相比，资深架构更得了解哪类组件该学，而且，每个组件内部的知识太多，比如Kafka的知识就能写至少一本书，对于资深架构而言，首先需要用较短的时间了解该组件（比如kafka）的架构以及和其它分布式组件（比如Flume）的整合方式，而且还得具备过滤知识的能力，即知道哪些知识不用学。这样一旦有需求，就可以较快地搭建出系统原型骨架，随后再逐步完善功能效果。
4 对于程序员而言，如何高效地升级到架构或资深架构？
当我还处在一般开发和高级开发的中间水平时，我认为我能很快地升级到架构师的水平，所谓无知者无畏。当我迈出升级的步伐时，刚开始，我突然发现升级的难度很大，从而无处下手，因为平时我缺乏实践架构师技能的实战机会。现在，通过一些努力，我虽然没有自信说自己一定达到了架构师的水平，但大多数架构师能干的活，我勉强能做好。而且我平时也在不断揣摩身边技术架构的思考方式和解决问题的方法，所以在这方面我自认为给出的建议不会耽误大家。
首先是巩固自己基本功方面的建议。
1 学再多的视频和材料，也不及动手实践一个案例。
比如，大家在学习消息队列时，一定得动手搭建个环境，最好用虚拟机模式分布式的场景，这时可能就有同学说了，环境太难搭建，怎么办？自己查资料，这种动手能力对架构师而言就属于基本功，如果这也做不好，那么也没希望升级到架构师了。
类似这样，大家可列个学习列表，网上升级到架构师的系列视频很多，质量高的也不少，都是别人的经验之谈，但如果就看理论，或者看关键点，这连架构师的面试都通过不了，更何况做实际的架构师的活。
2 平时不能畏难，一定得多解决问题。
在平时工作中，一定会出很多问题，而且不少是出在核心代码和底层代码里，这时就一定得通过看日志等方式去排查问题。 我知道，对很多想升级的高级开发而言，刚开始的时候一定很难，比如linux命令都不熟，或者效率很慢，别人都找出问题点了，自己才刚打开日志。其实大家都这样过来的，多查多练，最多三个月，动手能力一定能提升。
3 得锻炼自己在linux里（或在分布式环境里）部署系统部署组件的能力，尤其是部署集群的能力，在此基础上，通过各种工具能进行压力测试。
比如还是拿kafka来说，搭建好集群后，就可以用kafka自带的Performance来做压测。其实如果是自己练习，压测的结果没太大的意义，但这个流程走下来，一定能对搭建环境，使用工具和看日志等技巧就非常熟悉了。
4 尽量培养自己的调优意识。说这个话很虚，具体而言，自己得能通过各种数据库日志（比如各sql的运行时间）来找出长sql，并在此基础上通过执行计划来优化，又如，可以通过mp文件和GC日志来看虚拟机的内存使用曲线，看内存主要耗在哪些方面，如果是自己代码没写好那还好办，如果是耗在（中间件的）底层jar包里的代码里，那也得知道解决方案。
以上只是架构师所需要的基础技能， 其实如果能真正做到上述4点的话，大家离开架构师的水准也不远了，在此基础上，大家还得继续锻炼整合的能力。
从纵向来讲，需要进一步深化搭建集群的技能，比如能从底层代码的角度，了解集群的组成方式，这样的话，就能很清晰地了解到集群的扩展方式和性能调优点。
从横向来讲，需要进一步了解多种组件的整合方式，比如系统如何同日志组件整合，大数据分析工具如何同日志组件整合等。
剩下的就是不断积累经验技能了。
5 在升级路上，如何避免一些坑
我在平时还有机会接触一些大神，这些其实都是大神们的经验之谈。下面分享下在升级过程中应当避免哪些坑。
1 就像大家以前准备政治考试时，先准备大点，在保证大点不拉下的基础上，再详细复习每个大点里的细节。比如，可以先了解Spring Cloud里有哪些组件，比如Ribbon可以用来负载均衡，Hystrix可以用来容错等，先把Spring Cloud里诸多组件先了解个大概，能用它们搭建成一个微服务体系后，再深入了解其中每个组件的细节，比如Spring Cloud Stream里Kafka配置细节。
但我经过和多位架构师沟通，他们在升级时，多少都在这方面走过弯路，我自己有时候也会不知不觉陷入技术细节之中，而忘记我学这个技术的初衷。这里给大家的建议是，在明确学习目标后（比如要学Spring Cloud），刚开始别先自己闭门造车地为自己制定学习目标，可以先借鉴现有的视频讲解等的学习路线。制定学习计划时，以两到三天为单位，给自己定好一个短期目标，等到Spring Cloud组件全都了解后，再通过运行通若干个案例来深入了解组件的细节，这样就能控制住自己的学习步骤。
2 千万别理论和实际脱节。这似乎是废话，但我见过很多高级开发，平时就看视频和书，也不运行代码，结果进步的速度很慢。
如果没机会实践架构技能怎么办？看自己组里有没有架构的活。如果也没有怎么办？（别嫌我啰嗦）回家自己准备环境，按视频里的搭建架构环境。必要时，你甚至可以通过跳槽来换得一个架构师的实践机会。
3 架构师可以是技术控，但绝不能是完美主义，毕竟解决方案得和实际业务切合，并得考虑解决问题的成本。而且，架构师不能过于拘泥于细节，不能什么都事必躬亲，很多时候，得给出方向，或者把问题拆分成开发能理解的子问题，然后让手下人去干。 这似乎和技术没有关系，这就要求架构师更具备和人打交道的能力了，这点将在本文的第6部分详细说明。
6 指导技术难于自己实现功能，再论资深架构的协调（或者说扯皮）能力的炼成
不少开发者，尤其是资深开发者，或许都有这样的体会，对于一些功能，我宁可自己做，而不是把它们拆分成若干个子功能再安排手下人去做。或者我宁可去攻克一些技术的难题，也不愿意去和人扯皮，从而去制定架构里组件的选型方案。
可以这样说，架构师30%的价值来自他拥有的专业技能，30%的价值来自他分析和解决问题的能力，而40%的价值（甚至更高）来自于指导和协调能力。除去最后40%的价值，架构师其实和高级开发没什么差别。比如通过下面的例子，我们能看到架构师为什么还得具备指导和协调的能力。
案例1：当架构师被要求改善本公司系统（比如是个应用网站）的调用性能时，他就得和多个组打交道，往往是，有些组未必肯支持（毕竟现有系统用得不错谁都不愿改），或者具体的改善点需要一些组来落实，这就相当于增加该组的工作量了。
案例2：当架构师搭建好一套分布式缓存系统后，就得培训其它组的开发人员，让他们合理使用这套系统。
案例3：又如架构师帮一个组解决了一个典型的OOM问题后，得把解决这个问题的思路向其他组推广，以便节省解决同类问题的时间。
从上述案例中，我们一定能感受到在沟通，协调方面架构师需要掌握的技能水准。这方面说难不难，多练就行，但对IT开发而言，动嘴要比动手写代码要难。下面也给出些提升“动嘴”能力的技巧。
1 首先得提升自己综合逻辑思维的能力，这点可以靠多写博客，甚至写书来提升。其实写的时候，就相当于把自己要讲的内容用文字整理了一遍，这样无形中也提升了自己综合表达能力。
2 在组内要多分享技术。其实刚开始分享时，一定不知道该说什么，甚至讲完后没人能懂（当然自己一定能懂），但多讲几次后，口头表达和与别人的交流能力也上去了。
3 在遇到和其它组交流时（比如联调或沟通接口），一定得抓住机会多开口，刚开始的时候，估计很难让别人能接受自己的观点，或者自己有理也未必能讲清楚，但经过多次协调后，就能让别人接受自己的观点，或者大家能达成彼此能接受的妥协方案。
对本文感兴趣的Java工程师的朋友们可以私信我【Java架构】进我的粉丝群领取一些架构资料 电子书籍在群里也会有面试上的一些建议交流
最后一个小要求，可以帮我转发下！
G. 数据库为什么要分库分表
1 基本思想之什么是分库分表？
从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。
2 基本思想之为什么要分库分表？
数
据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增
删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、
数据处理能力都将遭遇瓶颈。
3 分库分表的实施策略。
分库分表有垂直切分和水平切分两种。
3.1
何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据
库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
3.2
何谓水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库
上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、
part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，
然后将这些表按照一定的规则存储到多个userDB上。
3.3 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。
而
如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体
的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。
4 分库分表存在的问题。
4.1 事务问题。
在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
4.2 跨库跨表的join问题。
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
4.3 额外的数据管理负担和数据运算压力。
额
外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于
一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order
by语句就可以搞定，但是在进行分表之后，将需要n个order
by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。