nosqlssdb主备,mysql数据库主备

为什么海量数据场景中NoSQL越来越重要

本质是因为：随着互联网的进一步发展与各行业信息化建设进程加快、参与者的增多，人们对软件有了更多更新的要求，需要软件不仅能实现功能，而且要求保证许多人可以共同参与使用，因而软件所需承载的数据量和吞吐量必须达到相应的需求。而目前的关系型数据库在某些方面有一些缺点，导致不能满足需要。

屏南网站制作公司哪家好，找创新互联！从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设等网站项目制作，到程序开发，运营维护。创新互联自2013年创立以来到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联。

具体则需要对比关系型数据库与Nosql之间的区别可以得出

关系型数据库

关系型数据库把所有的数据都通过行和列的二元表现形式表示出来。

关系型数据库的优势：

1. 保持数据的一致性（事务处理）

2.由于以标准化为前提，数据更新的开销很小（相同的字段基本上都只有一处）

3. 可以进行Join等复杂查询

其中能够保持数据的一致性是关系型数据库的最大优势。

关系型数据库的不足：

不擅长的处理

1. 大量数据的写入处理（这点尤为重要）

2. 为有数据更新的表做索引或表结构（schema）变更

3. 字段不固定时应用

4. 对简单查询需要快速返回结果的处理

--大量数据的写入处理

读写集中在一个数据库上让数据库不堪重负，大部分网站已使用主从复制技术实现读写分离，以提高读写性能和读库的可扩展性。

所以在进行大量数据操作时，会使用数据库主从模式。数据的写入由主数据库负责，数据的读入由从数据库负责，可以比较简单地通过增加从数据库来实现规模化，但是数据的写入却完全没有简单的方法来解决规模化问题。

第一，要想将数据的写入规模化，可以考虑把主数据库从一台增加到两台，作为互相关联复制的二元主数据库使用，确实这样可以把每台主数据库的负荷减少一半，但是更新处理会发生冲突，可能会造成数据的不一致，为了避免这样的问题，需要把对每个表的请求分别分配给合适的主数据库来处理。

第二，可以考虑把数据库分割开来，分别放在不同的数据库服务器上，比如将不同的表放在不同的数据库服务器上，数据库分割可以减少每台数据库服务器上的数据量，以便减少硬盘IO的输入、输出处理，实现内存上的高速处理。但是由于分别存储字不同服务器上的表之间无法进行Join处理，数据库分割的时候就需要预先考虑这些问题，数据库分割之后，如果一定要进行Join处理，就必须要在程序中进行关联，这是非常困难的。

--为有数据更新的表做索引或表结构变更

在使用关系型数据库时，为了加快查询速度需要创建索引，为了增加必要的字段就一定要改变表结构，为了进行这些处理，需要对表进行共享锁定，这期间数据变更、更新、插入、删除等都是无法进行的。如果需要进行一些耗时操作，例如为数据量比较大的表创建索引或是变更其表结构，就需要特别注意，长时间内数据可能无法进行更新。

--字段不固定时的应用

如果字段不固定，利用关系型数据库也是比较困难的，有人会说，需要的时候加个字段就可以了，这样的方法也不是不可以，但在实际运用中每次都进行反复的表结构变更是非常痛苦的。你也可以预先设定大量的预备字段，但这样的话，时间一长很容易弄不清除字段和数据的对应状态，即哪个字段保存有哪些数据。

--对简单查询需要快速返回结果的处理  （这里的“简单”指的是没有复杂的查询条件）

这一点称不上是缺点，但不管怎样，关系型数据库并不擅长对简单的查询快速返回结果，因为关系型数据库是使用专门的sql语言进行数据读取的，它需要对sql与越南进行解析，同时还有对表的锁定和解锁等这样的额外开销，这里并不是说关系型数据库的速度太慢，而只是想告诉大家若希望对简单查询进行高速处理，则没有必要非使用关系型数据库不可。

NoSQL数据库

关系型数据库应用广泛，能进行事务处理和表连接等复杂查询。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。

优点：

易于数据的分散

各个数据之间存在关联是关系型数据库得名的主要原因，为了进行join处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散，这也是关系型数据库并不擅长大数据量的写入处理的原因。相反NoSQL数据库原本就不支持Join处理，各个数据都是独立设计的，很容易把数据分散在多个服务器上，故减少了每个服务器上的数据量，即使要处理大量数据的写入，也变得更加容易，数据的读入操作当然也同样容易。

典型的NoSQL数据库

临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase）

一、 键值存储

它的数据是以键值的形式存储的，虽然它的速度非常快，但基本上只能通过键的完全一致查询获取数据，根据数据的保存方式可以分为临时性、永久性和两者兼具 三种。

（1）临时性

所谓临时性就是数据有可能丢失，memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止时，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据，旧数据会丢失。总结来说：

。在内存中保存数据

。可以进行非常快速的保存和读取处理

。数据有可能丢失

（2）永久性

所谓永久性就是数据不会丢失，这里的键值存储是把数据保存在硬盘上，与临时性比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的，但数据不会丢失是它最大的优势。总结来说：

。在硬盘上保存数据

。可以进行非常快速的保存和读取处理（但无法与memcached相比）

。数据不会丢失

（3） 两者兼备

Redis属于这种类型。Redis有些特殊，临时性和永久性兼具。Redis首先把数据保存在内存中，在满足特定条件（默认是 15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的键发生变更）的时候将数据写入到硬盘中，这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性，这种类型的数据库特别适合处理数组类型的数据。总结来说：

。同时在内存和硬盘上保存数据

。可以进行非常快速的保存和读取处理

。保存在硬盘上的数据不会消失（可以恢复）

。适合于处理数组类型的数据

二、面向文档的数据库

MongoDB、CouchDB属于这种类型，它们属于NoSQL数据库，但与键值存储相异。

（1）不定义表结构

即使不定义表结构，也可以像定义了表结构一样使用，还省去了变更表结构的麻烦。

（2）可以使用复杂的查询条件

跟键值存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据，虽然不具备事务处理和Join这些关系型数据库所具有的处理能力，但初次以外的其他处理基本上都能实现。

三、 面向列的数据库

Cassandra、HBae、HyperTable属于这种类型，由于近年来数据量出现爆发性增长，这种类型的NoSQL数据库尤其引入注目。

普通的关系型数据库都是以行为单位来存储数据的，擅长以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被成为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。

面向列的数据库具有搞扩展性，即使数据增加也不会降低相应的处理速度（特别是写入速度），所以它主要应用于需要处理大量数据的情况。另外，把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同，故应用起来十分困难。

总结：关系型数据库与NoSQL数据库并非对立而是互补的关系，即通常情况下使用关系型数据库，在适合使用NoSQL的时候使用NoSQL数据库，让NoSQL数据库对关系型数据库的不足进行弥补。

NoSQL-HDFS-基本概念

Hadoop

文件系统：文件系统是用来存储和管理文件，并且提供文件的查询、增加、删除等操作。

直观上的体验：在shell窗口输入 ls 命令，就可以看到当前目录下的文件夹、文件。

文件存储在哪里？硬盘

一台只有250G硬盘的电脑，如果需要存储500G的文件可以怎么办？先将电脑硬盘扩容至少250G，再将文件分割成多块，放到多块硬盘上储存。

通过 hdfs dfs -ls 命令可以查看分布式文件系统中的文件，就像本地的ls命令一样。

HDFS在客户端上提供了查询、新增和删除的指令，可以实现将分布在多台机器上的文件系统进行统一的管理。

在分布式文件系统中，一个大文件会被切分成块，分别存储到几台机器上。结合上文中提到的那个存储500G大文件的那个例子，这500G的文件会按照一定的大小被切分成若干块，然后分别存储在若干台机器上，然后提供统一的操作接口。

看到这里，不少人可能会觉得，分布式文件系统不过如此，很简单嘛。事实真的是这样的么？

潜在问题

假如我有一个1000台机器组成的分布式系统，一台机器每天出现故障的概率是0.1%，那么整个系统每天出现故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一个容错机制来保证发生差错时文件依然可以读出，这里暂时先不展开介绍。

如果要存储PB级或者EB级的数据，成千上万台机器组成的集群是很常见的，所以说分布式系统比单机系统要复杂得多呀。

这是一张HDFS的架构简图：

client通过nameNode了解数据在哪些DataNode上，从而发起查询。此外，不仅是查询文件，写入文件的时候也是先去请教NameNode，看看应该往哪个DateNode中去写。

为了某一份数据只写入到一个Datanode中，而这个Datanode因为某些原因出错无法读取的问题，需要通过冗余备份的方式来进行容错处理。因此，HDFS在写入一个数据块的时候，不会仅仅写入一个DataNode，而是会写入到多个DataNode中，这样，如果其中一个DataNode坏了，还可以从其余的DataNode中拿到数据，保证了数据不丢失。

实际上，每个数据块在HDFS上都会保存多份，保存在不同的DataNode上。这种是牺牲一定存储空间换取可靠性的做法。

接下来我们来看一下完整的文件写入的流程：

大文件要写入HDFS，client端根据配置将大文件分成固定大小的块，然后再上传到HDFS。

读取文件的流程：

1、client询问NameNode，我要读取某个路径下的文件，麻烦告诉我这个文件都在哪些DataNode上？

2、NameNode回复client，这个路径下的文件被切成了3块，分别在DataNode1、DataNode3和DataNode4上

3、client去找DataNode1、DataNode3和DataNode4，拿到3个文件块，通过stream读取并且整合起来

文件写入的流程：

1、client先将文件分块，然后询问NameNode，我要写入一个文件到某个路径下，文件有3块，应该怎么写？

2、NameNode回复client，可以分别写到DataNode1、DataNode2、DataNode3、DataNode4上，记住，每个块重复写3份，总共是9份

3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把数据写到他们上面

出于容错的考虑，每个数据块有3个备份，但是3个备份快都直接由client端直接写入势必会带来client端过重的写入压力，这个点是否有更好的解决方案呢？回忆一下mysql主备之间是通过binlog文件进行同步的，HDFS当然也可以借鉴这个思想，数据其实只需要写入到一个datanode上，然后由datanode之间相互进行备份同步，减少了client端的写入压力，那么至于是一个datanode写入成功即成功，还是需要所有的参与备份的datanode返回写入成功才算成功，是可靠性配置的策略，当然这个设置会影响到数据写入的吞吐率，我们可以看到可靠性和效率永远是“鱼和熊掌不可兼得”的。

潜在问题

NameNode确实会回放editlog，但是不是每次都从头回放，它会先加载一个fsimage，这个文件是之前某一个时刻整个NameNode的文件元数据的内存快照，然后再在这个基础上回放editlog，完成后，会清空editlog，再把当前文件元数据的内存状态写入fsimage，方便下一次加载。

这样，全量回放就变成了增量回放，但是如果NameNode长时间未重启过，editlog依然会比较大，恢复的时间依然比较长，这个问题怎么解呢？

SecondNameNode是一个NameNode内的定时任务线程，它会定期地将editlog写入fsimage，然后情况原来的editlog，从而保证editlog的文件大小维持在一定大小。

NameNode挂了， SecondNameNode并不能替代NameNode，所以如果集群中只有一个NameNode，它挂了，整个系统就挂了。hadoop2.x之前，整个集群只能有一个NameNode，是有可能发生单点故障的，所以hadoop1.x有本身的不稳定性。但是hadoop2.x之后，我们可以在集群中配置多个NameNode，就不会有这个问题了，但是配置多个NameNode，需要注意的地方就更多了，系统就更加复杂了。

俗话说“一山不容二虎”，两个NameNode只能有一个是活跃状态active，另一个是备份状态standby，我们看一下两个NameNode的架构图。

两个NameNode通过JournalNode实现同步editlog，保持状态一致可以相互替换。

因为active的NameNode挂了之后，standby的NameNode要马上接替它，所以它们的数据要时刻保持一致，在写入数据的时候，两个NameNode内存中都要记录数据的元信息，并保持一致。这个JournalNode就是用来在两个NameNode中同步数据的，并且standby NameNode实现了SecondNameNode的功能。

进行数据同步操作的过程如下：

active NameNode有操作之后，它的editlog会被记录到JournalNode中，standby NameNode会从JournalNode中读取到变化并进行同步，同时standby NameNode会监听记录的变化。这样做的话就是实时同步了，并且standby NameNode就实现了SecondNameNode的功能。

优点：

缺点：

为什么要使用NoSQL？NOSQL的优势

这次的NoSQL专栏系列将先整体介绍NoSQL，然后介绍如何把NoSQL运用到自己的项目中合适的场景中，还会适当地分析一些成功案例，希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。

NoSQL概念随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。）

NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。

在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。

到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。

Memcached+MySQL

后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。

Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时，如果你去面试，你说你有Memcached经验，肯定会加分的。

Mysql主从读写分离

由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

MySQL的扩展性瓶颈

在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。

关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。

NOSQL的优势易扩展NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。

总结NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。

为什么不用NoSQL

当为大家描述我们的整体服务架构时，最常见的两个问题是：

为什么采用结构化方式将数据存储在SQL数据库中，而不使用NoSQL平台？

为什么自己维护数据中心，而不将Evernote托管到云服务提供商？

这两个问题都很有趣，我们先来探讨第一个。

对特定的应用而言，相比一个单一的SQL实例，一个现代的键值存储引擎具备显著的性能优势和可扩展性。

CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

如果你在Windows客户端上创建了一个名为“Cooking”的记事本，并立即在其中粘贴了一个名为“Quick Tomato Sauce”的食谱，客户端会立刻进行如下同步：

调用NoteStore.createNotebook() 请求服务器创建记事本，并返回以创建记事本的GUID。

通过指定记事本的GUID，调用NoteStore.createNote()在记事本中创建笔记。

每次API调用都通过SQL事物予以实现，可以让客户端完全信任服务器的任何提示。ACID兼容的数据库可以做到这些：

原子性（Atomicity）：如果API调用成功，那么所有的改动都会保存；如果API调用失败，所有的改动都不会提交。

一致性（Consistency）： 在API调用完成后，所有的账户都可用，并能保证内部状态的一致性。每篇笔记都与记事本相关联，以避免出现孤立项。数据库不允许删除关联有记事的记事本，这得感谢FOREIGN KEY约束。

持久性（Durability）：当服务器发送记事本已创建完毕的回执后，客户端会认为它的存在具有持久性，以便进行后续的操作。变更的持久性，可以让客户端知道在任何时刻对服务状态的影响都能保持一致性。

对我们的同步协议而言，持久性最为重要。如果客户端不能确定服务器端的变更具有持久性，那么协议将会变得复杂而低效。

“大数据”问题

得益于事务处理的数据库的ACID属性，同样使得数据集非常难以扩展，以超出单台服务器的范围。数据库集群和多主复制技术并不理想，键值存储为实现可扩展性提供了一条捷径。

所幸，Evernote暂时不需要考虑这个问题。即便是我们有近10亿的笔记，和近20亿的资源文件，这也并不能称得上是一个大数据集。通过按用户分区，它被划分成了2千万个独立的数据集。

我们尚未遇到所谓“大数据”引发的问题，倒是遇到了许多“中数据”的存储问题，这就是通过规整分区形成的分片存储架构。

也许以后……

我们对新的存储系统非常感兴趣，非常乐意应用在哪些对ACID要求不强，但确实需要横向扩展的新项目中。例如，我们的报告分析系统已经逐渐超出了MySQL平台的承受力，需要被更快、更先进的系统所取代。

我们现在对以Evernote用户元数据为基础的MySQL分片存储颇为满意，尽管这不会引起那些IT弄潮儿的兴趣。

架构高可用高并发系统的设计原则

通过学习《亿级流量网站架构核心技术》及《linux就该这么学》学习笔记及自己的感悟：架构设计之高可用高并发系统设计原则，架构设计包括墨菲定律、康威定律和二八定律三大定律，而系统设计包括高并发原则、高可用和业务设计原则等。

架构设计三大定律

墨菲定律 – 任何事没有表面看起来那么简单 – 所有的事都会比预计的时间长 – 可能出错的事情总会出错 – 担心某种事情发生，那么它就更有可能发生

康威定律 – 系统架构师公司组织架构的反映 – 按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本 – 如果沟通出现问题，应该考虑进行系统和组织架构的调整 – 适合时机进行系统拆分，不要一开始就吧系统、服务拆分拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高 – 微服务架构的理论基础 – 康威定律– 每个架构师都应该研究下康威定律

二八定律 – 80%的结果取决于20%的原因

系统设计遵循的原则

1.高并发原则

无状态

无状态应用，便于水平扩展

有状态配置可通过配置中心实现无状态

实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等

拆分

系统维度：按照系统功能、业务拆分，如购物车，结算，订单等

功能维度：对系统功能在做细粒度拆分

读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表

AOP维度： 根据访问特征，按照AOP进行拆分，比如商品详情页可分为CDN、页面渲染系统，CDN就是一个AOP系统

模块维度：对整体代码结构划分Web、Service、DAO

服务化

服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理

考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等

实践：利用Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现自动注册和发现服

消息队列

目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等

大流量缓冲： 牺牲强一致性，保证最终一致性(案例：库存扣减，现在Redis中做扣减，记录扣减日志，通过后台进程将扣减日志应用到DB)

数据校对: 解决异步消息机制下消息丢失问题

数据异构

数据异构: 通过消息队列机制接收数据变更，原子化存储

数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环

缓存银弹

用户层:

DNS缓存

浏览器DNS缓存

操作系统DNS缓存

本地DNS服务商缓存

DNS服务器缓存

客户端缓存

浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)

App客户缓存(js/css/image…)

代理层：

CDN缓存(一般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-二级节点-中心节点-源站)

接入层：

Opcache： 缓存PHP的Opcodes

Proxy_cache： 代理缓存,可以存储到/dev/shm或者SSD

FastCGI Cache

Nginx+Lua+Redis: 业务数据缓存

Nginx为例：

PHP为例：

应用层：

页面静态化

业务数据缓存(Redis/Memcached/本地文件等)

消息队列

数据层：

NoSQL： Redis、Memcache、SSDB等

MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等

系统层：

CPU : L1/L2/L3 Cache/NUMA

内存

磁盘：磁盘本身缓存、dirtyratio/dirtybackground_ratio、阵列卡本身缓存

并发化

2.高可用原则

降级

降级开关集中化管理：将开关配置信息推送到各个应用

可降级的多级读服务：如服务调用降级为只读本地缓存

开关前置化：如Nginx+lua(OpenResty)配置降级策略，引流流量；可基于此做灰度策略

业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能

限流

目的: 防止恶意请求攻击或超出系统峰值

实践：

恶意请求流量只访问到Cache

穿透后端应用的流量使用Nginx的limit处理

恶意IP使用Nginx Deny策略或者iptables拒绝

切流量

目的：屏蔽故障机器

实践:

DNS: 更改域名解析入口，如DNSPOD可以添加备用IP，正常IP故障时，会自主切换到备用地址;生效实践较慢

HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度

LVS/HaProxy/Nginx: 摘除故障节点

可回滚

发布版本失败时可随时快速回退到上一个稳定版本

3.业务设计原则

防重设计

幂等设计

流程定义

状态与状态机

后台系统操作可反馈

后台系统审批化

文档注释

备份

4.总结

先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。

本文作者为网易高级运维工程师

ssdb、minio性能测试c

项目上需要找一个硬盘型的NoSQL，用于将 Redis 中的冷数据落入硬盘。初步选型了几款 key-value 类型的NoSQL，分别有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均为基于 levelDB 开发的几款NoSQL。其中因为 levelDB、rocksDB 无网络接口，不方便做分布式和高可用。， TiDB 过重，还有 swapDB 社区不够活跃且相关client API不完备。暂时选型 SSDB 。

项目需要存储的其实是一个略长的二进制字符串，初步认为，使用 对象存储 方案其实也可以替代NoSQL，所以压测对象添加当前非常火的云原生对象存储 MinIO

硬件名|配置 系统| Ubuntu(基于win10 wsl版的docker启动) 内存| 16GB(实际可用6.08G) CPU| Intel i5-8400

测试项目： 1. 写50M数据100次 2. 随机读取任意key 100次（对LRU机制不友好）

写

数据导入成功！

数据序列化成功！

a 数据大小:50.99295234680176 MB

第1次写入总用时: 797 ms

第2次写入总用时: 848 ms

第3次写入总用时: 3621 ms

第4次写入总用时: 813 ms

第5次写入总用时: 1862 ms

第6次写入总用时: 838 ms

第7次写入总用时: 2235 ms

第8次写入总用时: 836 ms

第9次写入总用时: 900 ms

第10次写入总用时: 1027 ms

第11次写入总用时: 1101 ms

第12次写入总用时: 880 ms

第13次写入总用时: 1956 ms

第14次写入总用时: 866 ms

第15次写入总用时: 2422 ms

第16次写入总用时: 852 ms

第17次写入总用时: 4511 ms

第18次写入总用时: 875 ms

第19次写入总用时: 2736 ms

第20次写入总用时: 814 ms

第21次写入总用时: 7172 ms

第22次写入总用时: 891 ms

第23次写入总用时: 7820 ms

第24次写入总用时: 836 ms

第25次写入总用时: 22103 ms

第26次写入总用时: 877 ms

第27次写入总用时: 2712 ms

第28次写入总用时: 841 ms

第29次写入总用时: 1928 ms

第30次写入总用时: 916 ms

第31次写入总用时: 839 ms

第32次写入总用时: 826 ms

第33次写入总用时: 7759 ms

第34次写入总用时: 843 ms

第35次写入总用时: 10670 ms

第36次写入总用时: 843 ms

第37次写入总用时: 9361 ms

第38次写入总用时: 821 ms

第39次写入总用时: 810 ms

第40次写入总用时: 794 ms

第41次写入总用时: 13281 ms

第42次写入总用时: 833 ms

第43次写入总用时: 811 ms

第44次写入总用时: 798 ms

第45次写入总用时: 18843 ms

第46次写入总用时: 911 ms

第47次写入总用时: 9428 ms

第48次写入总用时: 898 ms

第49次写入总用时: 17582 ms

第50次写入总用时: 903 ms

第51次写入总用时: 831 ms

第52次写入总用时: 800 ms

第53次写入总用时: 14602 ms

第54次写入总用时: 827 ms

第55次写入总用时: 5898 ms

第56次写入总用时: 856 ms

第57次写入总用时: 5693 ms

第58次写入总用时: 1050 ms

第59次写入总用时: 882 ms

第60次写入总用时: 1020 ms

第61次写入总用时: 15060 ms

第62次写入总用时: 902 ms

第63次写入总用时: 1062 ms

第64次写入总用时: 915 ms

第65次写入总用时: 7572 ms

第66次写入总用时: 823 ms

第67次写入总用时: 9649 ms

第68次写入总用时: 832 ms

第69次写入总用时: 10403 ms

第70次写入总用时: 907 ms

第71次写入总用时: 978 ms

第72次写入总用时: 789 ms

第73次写入总用时: 2111 ms

第74次写入总用时: 947 ms

第75次写入总用时: 4675 ms

第76次写入总用时: 944 ms

第77次写入总用时: 8592 ms

第78次写入总用时: 832 ms

第79次写入总用时: 2940 ms

第80次写入总用时: 842 ms

第81次写入总用时: 19835 ms

第82次写入总用时: 862 ms

第83次写入总用时: 7646 ms

第84次写入总用时: 873 ms

第85次写入总用时: 1002 ms

第86次写入总用时: 842 ms

第87次写入总用时: 9057 ms

第88次写入总用时: 801 ms

第89次写入总用时: 5117 ms

第90次写入总用时: 918 ms

第91次写入总用时: 798 ms

第92次写入总用时: 853 ms

第93次写入总用时: 7728 ms

第94次写入总用时: 810 ms

第95次写入总用时: 3969 ms

第96次写入总用时: 814 ms

第97次写入总用时: 2050 ms

第98次写入总用时: 819 ms

第99次写入总用时: 9566 ms

第100次写入总用时: 833 ms/pre

随机读

第1次读取 15总用时: 2251 ms

第2次读取 73总用时: 2045 ms

第3次读取 98总用时: 1548 ms

第4次读取 20总用时: 2683 ms

第5次读取 46总用时: 1156 ms

第6次读取 69总用时: 1160 ms

第7次读取 46总用时: 1520 ms

第8次读取 51总用时: 1381 ms

第9次读取 48总用时: 1000 ms

第10次读取 69总用时: 1400 ms

第11次读取 82总用时: 1236 ms

第12次读取 22总用时: 1140 ms

第13次读取 36总用时: 864 ms

第14次读取 66总用时: 843 ms

第15次读取 47总用时: 922 ms

第16次读取 17总用时: 885 ms

第17次读取 14总用时: 864 ms

第18次读取 64总用时: 888 ms

第19次读取 74总用时: 815 ms

第20次读取 33总用时: 866 ms

第21次读取 36总用时: 822 ms

第22次读取 78总用时: 975 ms

第23次读取 40总用时: 1186 ms

第24次读取 54总用时: 857 ms

第25次读取 92总用时: 963 ms

第26次读取 43总用时: 955 ms

第27次读取 38总用时: 853 ms

第28次读取 47总用时: 926 ms

第29次读取 62总用时: 877 ms

第30次读取 70总用时: 890 ms

第31次读取 88总用时: 895 ms

第32次读取 15总用时: 937 ms

第33次读取 3总用时: 993 ms

第34次读取 99总用时: 892 ms

第35次读取 76总用时: 818 ms

第36次读取 30总用时: 1020 ms

第37次读取 89总用时: 863 ms

第38次读取 99总用时: 819 ms

第39次读取 62总用时: 818 ms

第40次读取 1总用时: 871 ms

第41次读取 66总用时: 809 ms

第42次读取 68总用时: 847 ms

第43次读取 72总用时: 910 ms

第44次读取 50总用时: 1128 ms

第45次读取 47总用时: 898 ms

第46次读取 26总用时: 909 ms

第47次读取 35总用时: 872 ms

第48次读取 30总用时: 826 ms

第49次读取 79总用时: 904 ms

第50次读取 66总用时: 863 ms

第51次读取 2总用时: 885 ms

第52次读取 65总用时: 900 ms

第53次读取 67总用时: 1023 ms

第54次读取 16总用时: 934 ms

第55次读取 63总用时: 892 ms

第56次读取 9总用时: 894 ms

第57次读取 71总用时: 896 ms

第58次读取 20总用时: 947 ms

第59次读取 89总用时: 865 ms

第60次读取 57总用时: 872 ms

第61次读取 62总用时: 856 ms

第62次读取 14总用时: 881 ms

第63次读取 19总用时: 950 ms

第64次读取 14总用时: 876 ms

第65次读取 86总用时: 968 ms

第66次读取 12总用时: 911 ms

第67次读取 93总用时: 877 ms

第68次读取 59总用时: 886 ms

第69次读取 79总用时: 878 ms

第70次读取 49总用时: 869 ms

第71次读取 91总用时: 964 ms

第72次读取 38总用时: 838 ms

第73次读取 73总用时: 915 ms

第74次读取 8总用时: 875 ms

第75次读取 96总用时: 827 ms

第76次读取 98总用时: 826 ms

第77次读取 95总用时: 892 ms

第78次读取 36总用时: 843 ms

第79次读取 44总用时: 872 ms

第80次读取 89总用时: 863 ms

第81次读取 24总用时: 883 ms

第82次读取 89总用时: 804 ms

第83次读取 49总用时: 876 ms

第84次读取 81总用时: 873 ms

第85次读取 72总用时: 914 ms

第86次读取 68总用时: 861 ms

第87次读取 73总用时: 893 ms

第88次读取 4总用时: 880 ms

第89次读取 3总用时: 987 ms

第90次读取 76总用时: 896 ms

第91次读取 16总用时: 1010 ms

第92次读取 73总用时: 903 ms

第93次读取 83总用时: 933 ms

第94次读取 52总用时: 945 ms

第95次读取 48总用时: 901 ms

第96次读取 26总用时: 942 ms

第97次读取 37总用时: 883 ms

第98次读取 44总用时: 866 ms

第99次读取 89总用时: 921 ms

第100次读取 61总用时: 896 ms/pre

写

数据导入成功！

第1次写入总用时: 956 ms

第2次写入总用时: 912 ms

第3次写入总用时: 1241 ms

第4次写入总用时: 1564 ms

第5次写入总用时: 942 ms

第6次写入总用时: 3666 ms

第7次写入总用时: 1629 ms

第8次写入总用时: 1712 ms

第9次写入总用时: 977 ms

第10次写入总用时: 1515 ms

第11次写入总用时: 911 ms

第12次写入总用时: 1009 ms

第13次写入总用时: 1024 ms

第14次写入总用时: 1206 ms

第15次写入总用时: 984 ms

第16次写入总用时: 943 ms

第17次写入总用时: 954 ms

第18次写入总用时: 1033 ms

第19次写入总用时: 1008 ms

第20次写入总用时: 1121 ms

第21次写入总用时: 963 ms

第22次写入总用时: 949 ms

第23次写入总用时: 889 ms

第24次写入总用时: 1066 ms

第25次写入总用时: 1289 ms

第26次写入总用时: 1125 ms

第27次写入总用时: 1111 ms

第28次写入总用时: 953 ms

第29次写入总用时: 964 ms

第30次写入总用时: 1125 ms

第31次写入总用时: 998 ms

第32次写入总用时: 1993 ms

第33次写入总用时: 926 ms

第34次写入总用时: 920 ms

第35次写入总用时: 926 ms

第36次写入总用时: 1169 ms

第37次写入总用时: 1325 ms

第38次写入总用时: 1170 ms

第39次写入总用时: 1074 ms

第40次写入总用时: 1011 ms

第41次写入总用时: 931 ms

第42次写入总用时: 984 ms

第43次写入总用时: 1563 ms

第44次写入总用时: 905 ms

第45次写入总用时: 944 ms

第46次写入总用时: 1147 ms

第47次写入总用时: 1429 ms

第48次写入总用时: 934 ms

第49次写入总用时: 1133 ms

第50次写入总用时: 912 ms

第51次写入总用时: 953 ms

第52次写入总用时: 1127 ms

第53次写入总用时: 1065 ms

第54次写入总用时: 1323 ms

第55次写入总用时: 1003 ms

第56次写入总用时: 1489 ms

第57次写入总用时: 1377 ms

第58次写入总用时: 940 ms

第59次写入总用时: 1317 ms

第60次写入总用时: 912 ms

第61次写入总用时: 898 ms

第62次写入总用时: 934 ms

第63次写入总用时: 1005 ms

第64次写入总用时: 1729 ms

第65次写入总用时: 983 ms

第66次写入总用时: 1684 ms

第67次写入总用时: 908 ms

第68次写入总用时: 895 ms

第69次写入总用时: 1171 ms

第70次写入总用时: 1372 ms

第71次写入总用时: 1261 ms

第72次写入总用时: 1024 ms

第73次写入总用时: 1048 ms

第74次写入总用时: 904 ms

第75次写入总用时: 941 ms

第76次写入总用时: 928 ms

第77次写入总用时: 1806 ms

第78次写入总用时: 1052 ms

第79次写入总用时: 1030 ms

第80次写入总用时: 1092 ms

第81次写入总用时: 1117 ms

第82次写入总用时: 950 ms

第83次写入总用时: 933 ms

第84次写入总用时: 928 ms

第85次写入总用时: 935 ms

第86次写入总用时: 1908 ms

第87次写入总用时: 994 ms

第88次写入总用时: 1097 ms

第89次写入总用时: 930 ms

第90次写入总用时: 1052 ms

第91次写入总用时: 1119 ms

第92次写入总用时: 958 ms

第93次写入总用时: 987 ms

第94次写入总用时: 973 ms

第95次写入总用时: 2036 ms

第96次写入总用时: 891 ms

第97次写入总用时: 954 ms

第98次写入总用时: 951 ms

第99次写入总用时: 1044 ms

第100次写入总用时: 1366 ms/pre

随机读

第1次读取 46总用时: 40 ms

第2次读取 8总用时: 36 ms

第3次读取 28总用时: 26 ms

第4次读取 80总用时: 10 ms

第5次读取 77总用时: 13 ms

第6次读取 27总用时: 49 ms

第7次读取 86总用时: 20 ms

第8次读取 0总用时: 45 ms

第9次读取 54总用时: 34 ms

第10次读取 24总用时: 153 ms

第11次读取 78总用时: 29 ms

第12次读取 0总用时: 17 ms

第13次读取 91总用时: 56 ms

第14次读取 5总用时: 99 ms

第15次读取 23总用时: 138 ms

第16次读取 37总用时: 120 ms

第17次读取 40总用时: 156 ms

第18次读取 88总用时: 41 ms

第19次读取 76总用时: 32 ms

第20次读取 49总用时: 102 ms

第21次读取 20总用时: 179 ms

第22次读取 40总用时: 68 ms

第23次读取 6总用时: 215 ms

第24次读取 36总用时: 197 ms

第25次读取 37总用时: 30 ms

第26次读取 68总用时: 154 ms

第27次读取 14总用时: 314 ms

第28次读取 27总用时: 91 ms

第29次读取 51总用时: 255 ms

第30次读取 66总用时: 166 ms

第31次读取 86总用时: 140 ms

第32次读取 29总用时: 374 ms

第33次读取 96总用时: 235 ms

第34次读取 68总用时: 72 ms

第35次读取 74总用时: 264 ms

第36次读取 11总用时: 334 ms

第37次读取 55总用时: 316 ms

第38次读取 31总用时: 287 ms

第39次读取 93总用时: 233 ms

第40次读取 44总用时: 499 ms

第41次读取 26总用时: 312 ms

第42次读取 76总用时: 33 ms

第43次读取 11总用时: 31 ms

第44次读取 86总用时: 191 ms

第45次读取 96总用时: 217 ms

第46次读取 20总用时: 145 ms

第47次读取 1总用时: 772 ms

第48次读取 69总用时: 477 ms

第49次读取 9总用时: 320 ms

第50次读取 46总用时: 42 ms

第51次读取 34总用时: 823 ms

第52次读取 76总用时: 115 ms

第53次读取 62总用时: 635 ms

第54次读取 99总用时: 596 ms

第55次读取 64总用时: 657 ms

第56次读取 66总用时: 97 ms

第57次读取 18总用时: 461 ms

第58次读取 91总用时: 247 ms

第59次读取 46总用时: 147 ms

第60次读取 12总用时: 702 ms

第61次读取 79总用时: 545 ms

第62次读取 47总用时: 956 ms

第63次读取 17总用时: 853 ms

第64次读取 97总用时: 771 ms

第65次读取 74总用时: 368 ms

第66次读取 84总用时: 790 ms

第67次读取 72总用时: 866 ms

第68次读取 82总用时: 742 ms

第69次读取 93总用时: 313 ms

第70次读取 57总用时: 917 ms

第71次读取 61总用时: 1185 ms

第72次读取 66总用时: 162 ms

第73次读取 5总用时: 168 ms

第74次读取 68总用时: 275 ms

第75次读取 43总用时: 1108 ms

第76次读取 74总用时: 281 ms

第77次读取 65总用时: 955 ms

第78次读取 22总用时: 1169 ms

第79次读取 88总用时: 501 ms

第80次读取 80总用时: 1685 ms

第81次读取 92总用时: 1286 ms

第82次读取 89总用时: 1680 ms

第83次读取 30总用时: 1537 ms

第84次读取 41总用时: 1576 ms

第85次读取 2总用时: 2193 ms

第86次读取 52总用时: 1817 ms

第87次读取 8总用时: 323 ms

第88次读取 81总用时: 1409 ms

第89次读取 40总用时: 577 ms

第90次读取 88总用时: 598 ms

第91次读取 19总用时: 2324 ms

第92次读取 75总用时: 2275 ms

第93次读取 29总用时: 668 ms

第94次读取 77总用时: 2773 ms

第95次读取 62总用时: 484 ms

第96次读取 84总用时: 883 ms

第97次读取 32总用时: 2945 ms

第98次读取 44总用时: 884 ms

第99次读取 66总用时: 631 ms

第100次读取 38总用时: 2739 ms/pre

非常奇怪的是 MinIO 整体性能略优于 SSDB 但是理论上不太应该， SSDB 怎么说也是半内存半硬盘的NoSQL不应该比纯硬盘的 MinIO 性能要差，有可能是 SSDB 写到一定数据量后把本机内存写爆了，导致读写非常慢。但这变相验证了 SSDB 在极端情况下的不稳定。