• 关于

    单写多读不可用

    的搜索结果

回答

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念,不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持,这里可能会有疑惑,前面我们在介绍MongoDB时,说MongoDB是一个NoSQL数据库,不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事,如果你已经非常了解关系型数据库的事务,通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID? 1)MongoDB对原子性(Atomicity)的支持 原子性在Mongodb中到底是一个什么概念呢?为什么说支持但又说Mongodb的原子性是单行/文档级原子性,这里提供了一个MongoDB更新语句样例,如下图: MongoDB是如何实现事务的ACID? 更新“username”等于“tj.tang”的文档,更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新,这个概念在MySQL中可能你没有考虑过,但在MongoDB中由于文档可以嵌套子文档可以很复杂,所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的,如下情况: MongoDB是如何实现事务的ACID? MongoDB更新条件为工资小于50万的人都把工资调整为50万,这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时,出现宕机,服务器重启之后是无法像关系型数据库那样做到数据回滚的,也就是说处理这种多文档关系型数据库事务的支持,但MongoDB不支持。那么怎么解决Mongodb这个问题呢?可以通过建模,MongoDB不是范式而是反范式的设计,通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2)MongoDB对一致性(consistency)的支持 对于数据一致性来说,传统数据库(单机)跟分布式数据库(MongoDB)对于数据一致性是不太一样的,怎么理解呢?如下图: MongoDB是如何实现事务的ACID? 对于传统型数据库来说,数据一致性主要是在单机上,单机的问题主要是数据进来时的规则检验,数据不能被破坏掉。而在分布式数据库上,因为他们都是多节点分布式的,我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的,MongoDB支持强一致性或最终一致性(弱一致性),MongoDB的数据一致性也叫可调一致性,什么意思呢?如下图: MongoDB是如何实现事务的ACID? MongoDB的可调一致性,也就是可以自由选择强一致性或最终一致性,如果你的应用场景是前台的方式可以选择强一致性,如果你的应用场景是后台的方式(如报表)可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载,下面我们来看看这样做引发的一个问题:保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难,同步节点可能会故障,甚至会无法恢复,网络可能会有延迟或者丢包,网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中,通常有两个层次的一致性:第一种是强一致性,既集群中的所有机器状态同步保持一致。第二种是最终一致性,既可以允许短暂的数据不一致,但数据最终会保持一致。我们先来讲一下,在分布式集群中,为什么最终一致性通常是更合理的选择,然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢?其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出,称为CAP理论,尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳: 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。 分区容忍性(P):集群中的某些节点在无法联系后,集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。 要保证数据强一致性,最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功,也就是同步概念。而这时如果某个结点出现故障,那么写操作就成功不了了,需要一直等到这个节点恢复。也就是说,如果要保证强一致性,那么就无法提供7×24的高可用性。 而要保证可用性的话,就意味着节点在响应请求时,不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功,这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然,事实上还有其它的选择,比如在Yahoo的PNUTS中,采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现,所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证,要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的,但是作为一个整体,当客户端发起对某个key的数据请求时,整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中,一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时,需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系:R+W>N 下面举个实在的例子。比如我们设定N=3(数据会备份到A、B、C三个结点)。比如值 employee30:salary 当前的值是20000,我们想将其修改为30000。我们设定W=2,下面我们会对A、B、C三个节点发起写操作(employee30:salary, 30000),当A、B两个节点返回写成功后,协调器就会返回给客户端说写成功了。至于节点C,我们可以假设它从来没有收到这个写请求,他保存的依然是20000那个值。之后,当一个协调器执行一个对employee30:salary的读操作时,他还是会发三个请求给A、B、C三个节点: 如果设定R=1,那么当C节点先返回了20000这个值时,那我们客户端实际得到了一个错误的值。 如果设定R=2,则当协调器收到20000和30000两个值时,它会发现数据不太正确,并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性,在上面的应用场景中,我们需要设定R=2,W=2 如果写操作不能收到W个节点的成功返回,或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败,或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定,会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功,既W=N,那么只要有一个备份节点故障,写操作就失败了。一般设定是R+W = N+1,这是保证强一致性的最小设定了。一些强一致性的系统设定W=N,R=1,这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前,写操作是不会返回成功的。也就是说它的W=N,而读操作只需要读到一个值即可,也就是说它R=1。为了不至于让写操作太慢,对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后,会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort,Cassandra和Riak这些类Dynamo的系统,通常都允许用户按需要设置N,R,W三个值,即使是设置成W+R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性,或者是W 3)MongoDB对隔离性(isolation)的支持 在关系型数据库中,SQL2定义了四种隔离级别,分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准,比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改,哪些在事务内核事务外是可见的,哪些是不可见的。为了尽可能减少事务间的影响,事务隔离级别越高安全性越好但是并发就越差;事务隔离级别越低,事务请求的锁越少,或者保持锁的时间就越短,这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID? MongoDB在3.2之前使用的是“读未提交”,这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题: READ-UNCOMMITTED(读尚未提交的数据) 在这个级别,一个事务的修改,即使没有提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为“脏读(dirty read)”。这个级别会导致很多问题,从性能上来说,READ UNCOMMITTED不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。 READ-COMMITTED(读已提交的数据) 在这个级别,能满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读(non-repeatable read)”,因为两次执行同样的查询,可能会得到不一样的结果。 REPEATABLE-READ(可重复读) 在这个级别,保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC(multiversion concurrency control)解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息,也就是说这些数据数据库当前状态,这在一些对于数据的时效特别敏感的业务中,就很可能会出问题。 SERIALIZABLE(串行化) 在这个级别,它通过强制事务串行执行,避免了前面说的一系列问题。简单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别,主要应用在InnoDB存储引擎的分布式事务中。 4)MongoDB对持久性(durability)的支持 对于数据持久性来说,在传统数据库中(单机)的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题,因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID? 从上图可以看出,MongoDB同样是使用数据进来先写日志(日志刷盘的速度是非常快)然后在写入到数据库中的这种方式来保证数据的持久性,如果出现服务器宕机,当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging(预写日志系统),而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好,MongoDB的复制默认节点就是三节点以上的复制集群,当数据到达主节点之后会马上同步到从节点上去。

景凌凯 2019-12-02 02:05:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 本文描述了块存储性能的重要指标、不同块存储类型的性能、性能测试方式和结果解读。 衡量指标 衡量块存储产品的性能指标主要包括:IOPS、吞吐量和访问时延。 IOPS IOPS是Input/Output Operations per Second,即每秒能处理的I/O个数,用于表示块存储处理读写(输出/输入)的能力。如果要部署事务密集型应用,典型场景比如数据库类业务应用,需要关注IOPS性能。 最普遍的IOPS性能指标是顺序操作和随机操作,如下表所示。 IOPS性能指标 描述 总 IOPS 每秒执行的I/O操作总次数。 随机读IOPS 每秒执行的随机读I/O操作的平均次数 对硬盘存储位置的不连续访问。 随机写IOPS 每秒执行的随机写I/O操作的平均次数 顺序读IOPS 每秒执行的顺序读I/O操作的平均次数 对硬盘存储位置的连续访问。 顺序写IOPS 每秒执行的顺序写I/O操作的平均次数 吞吐量 吞吐量是指单位时间内可以成功传输的数据数量。 如果要部署大量顺序读写的应用,典型场景比如Hadoop离线计算型业务,需要关注吞吐量。 访问时延 访问时延是指块存储处理一个I/O需要的时间。 如果您的应用对时延比较敏感,比如数据库(过高的时延会导致应用性能下降或报错),建议您使用ESSD云盘、SSD云盘、SSD共享块存储或本地SSD盘类产品。 如果您的应用更偏重存储吞吐能力,对时延相对不太敏感,比如Hadoop离线计算等吞吐密集型应用,建议您使用本地HDD盘类产品,如d1或d1ne大数据型实例。 性能 以下是不同块存储产品的性能对比表。 云盘性能 四种云盘的性能对比如下表所示。 参数 ESSD云盘 SSD云盘 高效云盘 普通云盘 单盘最大容量 32768 GiB 32768 GiB 32768 GiB 2000 GiB 最大IOPS 1000000 25000* 5000 数百 最大吞吐量 4000 MBps 300 MBps* 140 MBps 30−40 MBps 单盘性能计算公式** IOPS = min{1200 + 100 * 容量, 1000000} IOPS = min{1800 + 30 * 容量, 25000} IOPS = min{1800 + 8 * 容量, 5000} 无 吞吐量 = min{80 + 1 * 容量, 4000} MBps 吞吐量 = min{120 + 0.5 * 容量, 300} MBps 吞吐量 = min{100+ 0.15 * 容量, 140} MBps 无 数据可靠性 99.9999999% 99.9999999% 99.9999999% 99.9999999% API名称 cloud_essd cloud_ssd cloud_efficiency cloud 典型应用场景 OLTP数据库:如MySQL、PostgreSQL、Oracle、SQL Server等关系型数据库 NoSQL数据库:如MongoDB、HBase、Cassandra等非关系型数据库 ElasticSearch分布式日志:ELK(Elasticsearch、Logstash和Kibana)日志分析等 PostgreSQL、MySQL、Oracle、SQL Server等中大型关系数据库应用 对数据可靠性要求高的中大型开发测试环境 MySQL、SQL Server、PostgreSQL等中小型关系数据库应用 对数据可靠性要求高、中度性能要求的中大型开发测试应用 数据不被经常访问或者低I/O负载的应用场景(如果应用需要更高的I/O性能,建议使用SSD云盘) 需要低成本并且有随机读写I/O的应用环境 * SSD云盘的性能因数据块大小而异,数据块越小,吞吐量越小,IOPS越高,如下表所示。只有挂载到I/O优化的实例时,SSD云盘才能获得期望的IOPS性能。挂载到非I/O优化的实例时,SSD云盘无法获得期望的IOPS性能。 数据块大小 IOPS最大值 吞吐量 4 KiB 约25000 很小,远低于300 MBps 16 KiB 约17200 将近300 MBps 32 KiB 约9600 64 KiB 约4800 ** 单盘性能计算公式说明: 以单块SSD云盘最大IOPS计算公式为例说明:起步1800 IOPS,每GiB增加30 IOPS,最高25000 IOPS。 以单块SSD云盘最大吞吐量计算公式为例说明:起步120 MBps,每GiB增加0.5 MBps,上限为 300 MBps的吞吐量。 不同云盘的单路随机写访问时延如下: ESSD云盘:0.1−0.2 ms SSD云盘:0.5−2 ms 高效云盘:1−3 ms 普通云盘:5−10 ms 共享块存储性能 2种共享块存储的性能对比如下表所示。 参数 SSD共享块存储 高效共享块存储 最大容量 单盘:32768 GiB 单个实例:最大128 TiB 单盘:32768 GiB 单个实例:最大128 TiB 最大随机读写IOPS* 30000 5000 最大顺序读写吞吐量* 512 MBps 160 MBps 单盘性能计算公式** IOPS = min{1600 + 40 * 容量, 30000} IOPS = min{1000 + 6 * 容量, 5000} 吞吐量 = min{100 + 0.5 * 容量, 512} MBps 吞吐量 = min{50 + 0.15 * 容量, 160} MBps 典型应用场景 Oracle RAC SQL Server 故障转移集群 服务器高可用 服务器高可用架构 开发测试数据库高可用架构 * 最大IOPS和吞吐量是在2个或2个以上实例同时压测裸设备能达到的性能数值。 ** 单盘性能计算公式说明: 以单块SSD共享块存储最大IOPS计算公式为例:起步1600 IOPS,每GiB增加40 IOPS,最高30000 IOPS。 以单块SSD共享块存储最大吞吐量计算公式为例:起步100 MBps,每GiB增加0.5 MBps,上限为512 MBps的吞吐量。 不同共享块存储的单路访问时延如下: SSD共享块存储:0.5−2 ms 高效共享块存储:1−3 ms 本地盘性能 本地盘的性能信息,请参考 本地盘。 性能测试 根据ECS实例的操作系统不同,您可以使用不同的工具测试块存储性能: Linux实例:可以使用DD、fio或sysbench等工具测试块存储性能。 Windows实例:可以使用fio、Iometer等工具测试块存储性能。 说明 在不同操作系统环境中,不同工具测试出来的硬盘基准性能会有差异。本文中所描述的性能参数,均为Linux实例下采用fio工具的测试结果,以此作为块存储产品性能指标参考。 本文以Linux实例和fio为例,说明如何使用fio测试块存储性能。在进行测试前,请确保块存储设备已经4 KiB对齐。 警告 测试裸盘可以获得真实的块存储盘性能,但直接测试裸盘会破坏文件系统结构,请在测试前提前做好数据备份。建议您只在新购无数据的ECS实例上使用工具测试块存储性能,避免造成数据丢失。 测试随机写IOPS,运行以下命令: fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Write_Testing 测试随机读IOPS,运行以下命令: fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Read_Testing 测试顺序写吞吐量,运行以下命令: fio -direct=1 -iodepth=64 -rw=write -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Write_PPS_Testing 测试顺序读吞吐量,运行以下命令: fio -direct=1 -iodepth=64 -rw=read -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Read_PPS_Testing 下表以测试随机写IOPS的命令为例,说明命令中各种参数的含义。 参数 说明 -direct=1 表示测试时忽略I/O缓存,数据直写。 -iodepth=128 表示使用AIO时,同时发出I/O数的上限为128。 -rw=randwrite 表示测试时的读写策略为随机写(random writes)。作其它测试时可以设置为: randread(随机读random reads) read(顺序读sequential reads) write(顺序写sequential writes) randrw(混合随机读写mixed random reads and writes) -ioengine=libaio 表示测试方式为libaio(Linux AIO,异步I/O)。应用程序使用I/O通常有两种方式: 同步 同步的I/O一次只能发出一个I/O请求,等待内核完成才返回。这样对于单个线程iodepth总是小于1,但是可以透过多个线程并发执行来解决。通常会用16−32根线程同时工作将iodepth塞满。 异步 异步的I/O通常使用libaio这样的方式一次提交一批I/O请求,然后等待一批的完成,减少交互的次数,会更有效率。 -bs=4k 表示单次I/O的块文件大小为4 KB。未指定该参数时的默认大小也是4 KB。 测试IOPS时,建议将bs设置为一个比较小的值,如本示例中的4k。 测试吞吐量时,建议将bs设置为一个较大的值,如本示例中的1024k。 -size=1G 表示测试文件大小为1 GiB。 -numjobs=1 表示测试线程数为1。 -runtime=1000 表示测试时间为1000秒。如果未配置,则持续将前述-size指定大小的文件,以每次-bs值为分块大小写完。 -group_reporting 表示测试结果里汇总每个进程的统计信息,而非以不同job汇总展示信息。 -filename=iotest 指定测试文件的名称,比如iotest。测试裸盘可以获得真实的硬盘性能,但直接测试裸盘会破坏文件系统结构,请在测试前提前做好数据备份。 -name=Rand_Write_Testing 表示测试任务名称为Rand_Write_Testing,可以随意设定。

2019-12-01 22:57:08 0 浏览量 回答数 0

回答

面试官心理分析 如果有人问到你 MQ 的知识,高可用是必问的。上一讲提到,MQ 会导致系统可用性降低。所以只要你用了 MQ,接下来问的一些要点肯定就是围绕着 MQ 的那些缺点怎么来解决了。 要是你傻乎乎的就干用了一个 MQ,各种问题从来没考虑过,那你就杯具了,面试官对你的感觉就是,只会简单使用一些技术,没任何思考,马上对你的印象就不太好了。这样的同学招进来要是做个 20k 薪资以内的普通小弟还凑合,要是做薪资 20k+ 的高工,那就惨了,让你设计个系统,里面肯定一堆坑,出了事故公司受损失,团队一起背锅。 面试题剖析 这个问题这么问是很好的,因为不能问你 Kafka 的高可用性怎么保证?ActiveMQ 的高可用性怎么保证?一个面试官要是这么问就显得很没水平,人家可能用的就是 RabbitMQ,没用过 Kafka,你上来问人家 Kafka 干什么?这不是摆明了刁难人么。 所以有水平的面试官,问的是 MQ 的高可用性怎么保证?这样就是你用过哪个 MQ,你就说说你对那个 MQ 的高可用性的理解。 RabbitMQ 的高可用性 RabbitMQ 是比较有代表性的,因为是基于主从(非分布式)做高可用性的,我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。 RabbitMQ 有三种模式:单机模式、普通集群模式、镜像集群模式。 单机模式 单机模式,就是 Demo 级别的,一般就是你本地启动了玩玩儿的,没人生产用单机模式。 普通集群模式(无高可用性) 普通集群模式,意思就是在多台机器上启动多个 RabbitMQ 实例,每个机器启动一个。你创建的 queue,只会放在一个 RabbitMQ 实例上,但是每个实例都同步 queue 的元数据(元数据可以认为是 queue 的一些配置信息,通过元数据,可以找到 queue 所在实例)。你消费的时候,实际上如果连接到了另外一个实例,那么那个实例会从 queue 所在实例上拉取数据过来。 这种方式确实很麻烦,也不怎么好,没做到所谓的分布式,就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据,要么固定连接那个 queue 所在实例消费数据,前者有数据拉取的开销,后者导致单实例性能瓶颈。 而且如果那个放 queue 的实例宕机了,会导致接下来其他实例就无法从那个实例拉取,如果你开启了消息持久化,让 RabbitMQ 落地存储消息的话,消息不一定会丢,得等这个实例恢复了,然后才可以继续从这个 queue 拉取数据。 所以这个事儿就比较尴尬了,这就没有什么所谓的高可用性,这方案主要是提高吞吐量的,就是说让集群中多个节点来服务某个 queue 的读写操作。 镜像集群模式(高可用性) 这种模式,才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是,在镜像集群模式下,你创建的 queue,无论元数据还是 queue 里的消息都会存在于多个实例上,就是说,每个 RabbitMQ 节点都有这个 queue 的一个完整镜像,包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候,都会自动把消息同步到多个实例的 queue 上。 那么如何开启这个镜像集群模式呢?其实很简单,RabbitMQ 有很好的管理控制台,就是在后台新增一个策略,这个策略是镜像集群模式的策略,指定的时候是可以要求数据同步到所有节点的,也可以要求同步到指定数量的节点,再次创建 queue 的时候,应用这个策略,就会自动将数据同步到其他的节点上去了。 这样的话,好处在于,你任何一个机器宕机了,没事儿,其它机器(节点)还包含了这个 queue 的完整数据,别的 consumer 都可以到其它节点上去消费数据。坏处在于,第一,这个性能开销也太大了吧,消息需要同步到所有机器上,导致网络带宽压力和消耗很重!第二,这么玩儿,不是分布式的,就没有扩展性可言了,如果某个 queue 负载很重,你加机器,新增的机器也包含了这个 queue 的所有数据,并没有办法线性扩展你的 queue。你想,如果这个 queue 的数据量很大,大到这个机器上的容量无法容纳了,此时该怎么办呢? Kafka 的高可用性 Kafka 一个最基本的架构认识:由多个 broker 组成,每个 broker 是一个节点;你创建一个 topic,这个 topic 可以划分为多个 partition,每个 partition 可以存在于不同的 broker 上,每个 partition 就放一部分数据。 这就是天然的分布式消息队列,就是说一个 topic 的数据,是分散放在多个机器上的,每个机器就放一部分数据。 实际上 RabbitMQ 之类的,并不是分布式消息队列,它就是传统的消息队列,只不过提供了一些集群、HA(High Availability, 高可用性) 的机制而已,因为无论怎么玩儿,RabbitMQ 一个 queue 的数据都是放在一个节点里的,镜像集群下,也是每个节点都放这个 queue 的完整数据。 Kafka 0.8 以前,是没有 HA 机制的,就是任何一个 broker 宕机了,那个 broker 上的 partition 就废了,没法写也没法读,没有什么高可用性可言。 比如说,我们假设创建了一个 topic,指定其 partition 数量是 3 个,分别在三台机器上。但是,如果第二台机器宕机了,会导致这个 topic 的 1/3 的数据就丢了,因此这个是做不到高可用的。 Kafka 0.8 以后,提供了 HA 机制,就是 replica(复制品) 副本机制。每个 partition 的数据都会同步到其它机器上,形成自己的多个 replica 副本。所有 replica 会选举一个 leader 出来,那么生产和消费都跟这个 leader 打交道,然后其他 replica 就是 follower。写的时候,leader 会负责把数据同步到所有 follower 上去,读的时候就直接读 leader 上的数据即可。只能读写 leader?很简单,要是你可以随意读写每个 follower,那么就要 care 数据一致性的问题,系统复杂度太高,很容易出问题。Kafka 会均匀地将一个 partition 的所有 replica 分布在不同的机器上,这样才可以提高容错性。 这么搞,就有所谓的高可用性了,因为如果某个 broker 宕机了,没事儿,那个 broker上面的 partition 在其他机器上都有副本的。如果这个宕机的 broker 上面有某个 partition 的 leader,那么此时会从 follower 中重新选举一个新的 leader 出来,大家继续读写那个新的 leader 即可。这就有所谓的高可用性了。 写数据的时候,生产者就写 leader,然后 leader 将数据落地写本地磁盘,接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了,就会发送 ack 给 leader,leader 收到所有 follower 的 ack 之后,就会返回写成功的消息给生产者。(当然,这只是其中一种模式,还可以适当调整这个行为) 消费的时候,只会从 leader 去读,但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候,这个消息才会被消费者读到。 看到这里,相信你大致明白了 Kafka 是如何保证高可用机制的了,对吧?不至于一无所知,现场还能给面试官画画图。要是遇上面试官确实是 Kafka 高手,深挖了问,那你只能说不好意思,太深入的你没研究过。

剑曼红尘 2020-04-17 09:31:13 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

问题

【Java问答学堂】2期 如何保证消息队列的高可用?

剑曼红尘 2020-04-17 09:04:32 75 浏览量 回答数 2

回答

参考:https://www.iteblog.com/archives/2530.html分布式和去中心化(Distributed and Decentralized)Cassandra 是分布式的,这意味着它可以运行在多台机器上,并呈现给用户一个一致的整体。事实上,在一个节点上运行 Cassandra 是没啥用的,虽然我们可以这么做,并且这可以帮助我们了解它的工作机制,但是你很快就会意识到,需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行,更为多机架部署进行了优化,甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上,Cassandra 都会收到数据。对于很多存储系统(比如 MySQL, Bigtable),一旦你开始扩展它,就需要把某些节点设为主节点,其他则作为从节点。但 Cassandra 是无中心的,也就是说每个节点都是一样的。与主从结构相反,Cassandra 的协议是 P2P 的,并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理:一文了解 Gossip 协议》。去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样, 所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称(server symmetry)。综上所述,Cassandra 是分布式、无中心的,它不会有单点失效,所以支持高可用性。弹性可扩展(Elastic Scalability)可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展,是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器,每台机器提供全部或部分数据,这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。弹性可扩展是指水平扩展的特性,意即你的集群可以不间断的情况下,方便扩展或缩减服务的规模。这样,你就不需要重新启动进程,不必修改应用的查询,也无需自己手工重新均衡数据分布。在 Cassandra 里,你只要加入新的计算机,Cassandra 就会自动地发现它并让它开始工作。高可用和容错(High Availability and Fault Tolerance)从一般架构的角度来看,系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障,从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况,所以它们一般都有硬件冗余,并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中端的功能在剩余系统上进行恢复。Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心里,从而提供更好的本地访问性能,并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。可调节的一致性(Tuneable Consistency)2000年,加州大学伯克利分校的 Eric Brewer 在 ACM 分布式计算原理会议提出了著名的 CAP 定律。CAP 定律表明,对于任意给定的系统,只能在一致性(Consistency)、可用性(Availability)以及分区容错性(Partition Tolerance)之间选择两个。关于 CAP 定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及 BASE 理论》以及《一篇文章搞清楚什么是分布式系统 CAP 定理》。所以 Cassandra 在设计的时候也不得不考虑这些问题,因为分区容错性这个是每个分布式系统必须考虑的,所以只能在一致性和可用性之间做选择,而 Cassandra 的应用场景更多的是为了满足可用性,所以我们只能牺牲一致性了。但是根据 BASE 理论,我们其实可以通过牺牲强一致性获得可用性。Cassandra 提供了可调节的一致性,允许我们选定需要的一致性水平与可用性水平,在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前,必须阻塞系统。这是通过设置副本因子(replication factor)来调节与之相对的一致性级别。通过副本因子(replication factor),你可以决定准备牺牲多少性能来换取一致性。 副本因子是你要求更新在集群中传播到的节点数(注意,更新包括所有增加、删除和更新操作)。客户端每次操作还必须设置一个一致性级别(consistency level)参数,这个参数决定了多少个副本写入成功才可以认定写操作是成功的,或者读取过程中读到多少个副本正确就可以认定是读成功的。这里 Cassandra 把决定一致性程度的权利留给了客户自己。所以,如果需要的话,你可以设定一致性级别和副本因子相等,从而达到一个较高的一致性水平,不过这样就必须付出同步阻塞操作的代价,只有所有节点都被更新完成才能成功返回一次更新。而实际上,Cassandra 一般都不会这么来用,原因显而易见(这样就丧失了可用性目标,影响性能,而且这不是你选择 Cassandra 的初衷)。而如果一个客户端设置一致性级别低于副本因子的话,即使有节点宕机了,仍然可以写成功。总体来说,Cassandra 更倾向于 CP,虽然它也可以通过调节一致性水平达到 AP;但是不推荐你这么设置。面向行(Row-Oriented)Cassandra 经常被看做是一种面向列(Column-Oriented)的数据库,这也并不算错。它的数据结构不是关系型的,而是一个多维稀疏哈希表。稀疏(Sparse)意味着任何一行都可能会有一列或者几列,但每行都不一定(像关系模型那样)和其他行有一样的列。每行都有一个唯一的键值,用于进行数据访问。所以,更确切地说,应该把 Cassandra 看做是一个有索引的、面向行的存储系统。Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段,还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中,不必进行长达数月的预先分析。对于使用 Cassandra 的应用,如果业务发生变化了,只需要在运行中增加或删除某些字段就行了,不会造成服务中断。当然, 这不是说你不需要考虑数据。相反,Cassandra 需要你换个角度看数据。在 RDBMS 里, 你得首先设计一个完整的数据模型, 然后考虑查询方式, 而在 Cassandra 里,你可以首先思考如何查询数据,然后提供这些数据就可以了。灵活的模式(Flexible Schema)Cassandra 的早期版本支持无模式(schema-free)数据模型,可以动态定义新的列。 无模式数据库(如 Bigtable 和 MongoDB)在访问大量数据时具有高度可扩展性和高性能的优势。 无模式数据库的主要缺点是难以确定数据的含义和格式,这限制了执行复杂查询的能力。为了解决这些问题,Cassandra 引入了 Cassandra Query Language(CQL),它提供了一种通过类似于结构化查询语言(SQL)的语法来定义模式。 最初,CQL 是作为 Cassandra 的另一个接口,并且基于 Apache Thrift 项目提供无模式的接口。 在这个过渡阶段,术语“模式可选”(Schema-optional)用于描述数据模型,我们可以使用 CQL 的模式来定义。并且可以通过 Thrift API 实现动态扩展以此添加新的列。 在此期间,基础数据存储模型是基于 Bigtable 的。从 3.0 版本开始,不推荐使用基于 Thrift API 的动态列创建的 API,并且 Cassandra 底层存储已经重新实现了,以更紧密地与 CQL 保持一致。 Cassandra 并没有完全限制动态扩展架构的能力,但它的工作方式却截然不同。 CQL 集合(比如 list、set、尤其是 map)提供了在无结构化的格式里面添加内容的能力,从而能扩展现有的模式。CQL 还提供了改变列的类型的能力,以支持 JSON 格式的文本的存储。因此,描述 Cassandra 当前状态的最佳方式可能是它支持灵活的模式。高性能(High Performance)Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能,并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器,存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现,在一个非常普通的工作站上,Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器,你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

封神 2019-12-02 02:00:50 0 浏览量 回答数 0

问题

如何保证消息队列的高可用?【Java问答学堂】20期

剑曼红尘 2020-05-18 11:21:10 2 浏览量 回答数 1

问题

快速入门PostgreSQL版-创建实例

李沃晟 2019-12-01 21:37:49 465 浏览量 回答数 0

回答

在primary-secondary 类型的协议中,副本被分为两大类,其中有且仅有一个副本作为primary 副本, 除primary 以外的副本都作为secondary 副本。维护primary 副本的节点作为中心节点,中心节点负 责维护数据的更新、并发控制、协调副本的一致性。 Primary-secondary 类型的协议一般要解决四大类问题:数据更新流程、数据读取方式、Primary 副本的确定和切换、数据同步(reconcile)。 数据更新基本流程 1. 数据更新都由primary 节点协调完成。 2. 外部节点将更新操作发给primary 节点 3. primary 节点进行并发控制即确定并发更新操作的先后顺序 4. primary 节点将更新操作发送给secondary 节点 5. primary 根据secondary 节点的完成情况决定更新是否成功并将结果返回外部节点 在工程实践中,如果由primary 直接同时发送给其他N 个副本发送数据,则每个 secondary 的更新吞吐受限于primary 总的出口网络带宽,最大为primary 网络出口带宽的1/N。为了 解决这个问题,有些系统(例如,GFS),使用接力的方式同步数据,即primary 将更新发送给第一 个secondary 副本,第一个secondary 副本发送给第二secondary 副本,依次类推。 数据读取方式 数据读取方式也与一致性高度相关。如果只需要最终一致性,则读取任何副本都可以满足需求。如果需要会 话一致性,则可以为副本设置版本号,每次更新后递增版本号,用户读取副本时验证版本号,从而 保证用户读到的数据在会话范围内单调递增。使用primary-secondary 比较困难的是实现强一致性。 由于数据的更新流程都是由primary 控制的,primary 副本上的数据一定是最新的,所以 如果始终只读primary 副本的数据,可以实现强一致性。如果只读primary 副本,则secondary 副本 将不提供读服务。实践中,如果副本不与机器绑定,而是按照数据段为单位维护副本,仅有primary 副本提供读服务在很多场景下并不会造出机器资源浪费。 将副本分散到集群中个,假设primary 也是随机的确定的,那么每台机器 上都有一些数据的primary 副本,也有另一些数据段的secondary 副本。从而某台服务器实际都提供 读写服务。 - 由primary 控制节点secondary 节点的可用性。当primary 更新某个secondary 副本不成功 时,primary 将该secondary 副本标记为不可用,从而用户不再读取该不可用的副本。不可用的 secondary 副本可以继续尝试与primary 同步数据,当与primary 完成数据同步后,primary 可以副本 标记为可用。这种方式使得所有的可用的副本,无论是primary 还是secondary 都是可读的,且在一 个确定的时间内,某secondary 副本要么更新到与primary 一致的最新状态,要么被标记为不可用, 从而符合较高的一致性要求。这种方式依赖于一个中心元数据管理系统,用于记录哪些副本可用, 哪些副本不可用。某种意义上,该方式通过降低系统的可用性来提高系统的一致性。 primary 副本的确定与切换 在primary-secondary 类型的协议中,另一个核心的问题是如何确定primary 副本,尤其是在原 primary 副本所在机器出现宕机等异常时,需要有某种机制切换primary 副本,使得某个secondary 副本成为新的primary 副本。 通常的,在primary-secondary 类型的分布式系统中,哪个副本是primary 这一信息都属于元信 息,由专门的元数据服务器维护。执行更新操作时,首先查询元数据服务器获取副本的primary 信 息,从而进一步执行数据更新流程。 由于分布式系统中可靠的发现节点异常是需要一定的探测时间的,这样的探测时间通常是10 秒级别,这也意味着一旦primary 异常,最多需要10 秒级别的 发现时间,系统才能开始primary 的切换,在这10 秒时间内,由于没有primary,系统不能提供更 新服务,如果系统只能读primary 副本,则这段时间内甚至不能提供读服务。从这里可以看到, primary-backup 类副本协议的最大缺点就是由于primary 切换带来的一定的停服务时间。 数据同步 不一致的secondary 副本需要与primary 进行同步(reconcile)。 通常不一致的形式有三种:一、由于网络分化等异常,secondary 上的数据落后于primary 上的 数据。二、在某些协议下,secondary 上的数据有可能是脏数据,需要被丢弃。所谓脏数据是由于 primary 副本没有进行某一更新操作,而secondary 副本上反而进行的多余的修改操作,从而造成 secondary 副本数据错误。三、secondary 是一个新增加的副本,完全没有数据,需要从其他副本上 拷贝数据。 对于第一种secondary 数据落后的情况,常见的同步方式是回放primary 上的操作日志(通常是 redo 日志),从而追上primary 的更新进度。对于脏数据的情况, 较好的做法是设计的分布式协议不产生脏数据。如果协议一定有产生脏数据的可能,则也应该使得 产生脏数据的概率降到非常低得情况,从而一旦发生脏数据的情况可以简单的直接丢弃有脏数据的 副本,这样相当于副本没有数据。另外,也可以设计一些基于undo 日志的方式从而可以删除脏数据。 如果secondary 副本完全没有数据,则常见的做法是直接拷贝primary 副本的数据,这种方法往往比 回放日志追更新进度的方法快很多。但拷贝数据时primary 副本需要能够继续提供更新服务,这就 要求primary 副本支持快照(snapshot)功能。即对某一刻的副本数据形成快照,然后拷贝快照,拷贝 完成后使用回放日志的方式追快照形成后的更新操作。

kun坤 2020-04-24 15:30:53 0 浏览量 回答数 0

问题

如何保证缓存与数据库的双写一致性?【Java问答】38期

剑曼红尘 2020-06-16 12:58:57 36 浏览量 回答数 1

问题

HBase Read Replicas功能介绍系列

pandacats 2019-12-20 19:45:55 4 浏览量 回答数 0

回答

Redis常见的几种主要使用方式: Redis 单副本 Redis 多副本(主从) Redis Sentinel(哨兵) Redis Cluster(集群) Redis 自研 Redis各种使用方式的优缺点: 1 Redis单副本 Redis各种使用方式的优缺点: Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 2 Redis多副本(主从) Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。 优点: 1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。 2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。 缺点: 1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。 2、主库的写能力受到单机的限制,可以考虑分片 3、主库的存储能力受到单机的限制,可以考虑Pika 4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。 使用场景 对 Redis 协议兼容性要求较高的业务 标准版完全兼容 Redis 协议,业务可以平滑迁移。 Redis 作为持久化数据存储使用的业务 标准版提供持久化机制及备份恢复机制,极大地保证数据可靠性。 单个 Redis 性能压力可控 由于 Redis 原生采用单线程机制,性能在10万 QPS 以下的业务建议使用。如果需要更高的性能要求,请选用集群版本。 Redis 命令相对简单,排序、计算类命令较少 由于 Redis 的单线程机制,CPU 会成为主要瓶颈。如排序、计算类较多的业务建议选用集群版配置。 3 Redis Sentinel(哨兵) Redis Sentinel是社区版本推出的原生高可用解决方案,Redis Sentinel部署架构主要包括两部分:Redis Sentinel集群和Redis数据集群,其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群。可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1(n>=1)的奇数个。 优点: 1、Redis Sentinel集群部署简单 2、能够解决Redis主从模式下的高可用切换问题 3、很方便实现Redis数据节点的线形扩展,轻松突破Redis自身单线程瓶颈,可极大满足对Redis大容量或高性能的业务需求。 4、可以实现一套Sentinel监控一组Redis数据节点或多组数据节点 缺点: 1、部署相对Redis 主从模式要复杂一些,原理理解更繁琐 2、资源浪费,Redis数据节点中slave节点作为备份节点不提供服务 3、Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换,对Redis的数据节点做失败判定分为主观下线和客观下线两种,对于Redis的从节点有对节点做主观下线操作,并不执行故障转移。 4、不能解决读写分离问题,实现起来相对复杂 建议: 1、如果监控同一业务,可以选择一套Sentinel集群监控多组Redis数据节点的方案,反之选择一套Sentinel监控一组Redis数据节点的方案 2、sentinel monitor 配置中的 建议设置成Sentinel节点的一半加1,当Sentinel部署在多个IDC的时候,单个IDC部署的Sentinel数量不建议超过(Sentinel数量 – quorum)。 3、合理设置参数,防止误切,控制切换灵敏度控制 quorum down-after-milliseconds 30000 failover-timeout 180000 maxclient timeout 4、部署的各个节点服务器时间尽量要同步,否则日志的时序性会混乱 5、Redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求效率 6、自行搞定配置中心(zookeeper),方便客户端对实例的链接访问 4 Redis Cluster(集群) Redis Cluster是社区版推出的Redis分布式集群解决方案,主要解决Redis分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster能起到很好的负载均衡的目的。Redis Cluster集群节点最小配置6个节点以上(3主3从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用。Redis Cluster采用虚拟槽分区,所有的键根据哈希函数映射到0~16383个整数槽内,每个节点负责维护一部分槽以及槽所印映射的键值数据。 优点: 1、无中心架构 2、数据按照slot存储分布在多个节点,节点间数据共享,可动态调整数据分布。 3、可扩展性,可线性扩展到1000多个节点,节点可动态添加或删除。 4、高可用性,部分节点不可用时,集群仍可用。通过增加Slave做standby数据副本,能够实现故障自动failover,节点之间通过gossip协议交换状态信息,用投票机制完成Slave到Master的角色提升。 5、降低运维成本,提高系统的扩展性和可用性。 缺点: 1、Client实现复杂,驱动要求实现Smart Client,缓存slots mapping信息并及时更新,提高了开发难度,客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。 2、节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout),被判断下线,这种failover是没有必要的。 3、数据通过异步复制,不保证数据的强一致性。 4、多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况。 5、Slave在集群中充当“冷备”,不能缓解读压力,当然可以通过SDK的合理设计来提高Slave资源的利用率。 6、key批量操作限制,如使用mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于keys 不支持跨slot查询,所以执行mset、mget、sunion等操作支持不友好。 7、key事务操作支持有限,只支持多key在同一节点上的事务操作,当多个key分布于不同的节点上时无法使用事务功能。 8、key作为数据分区的最小粒度,因此不能将一个很大的键值对象如hash、list等映射到不同的节点。 9、不支持多数据库空间,单机下的redis可以支持到16个数据库,集群模式下只能使用1个数据库空间,即db 0。 10、复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。 11、避免产生hot-key,导致主库节点成为系统的短板。 12、避免产生big-key,导致网卡撑爆、慢查询等。 13、重试时间应该大于cluster-node-time时间 14、Redis Cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。 使用场景 数据量较大 Redis 集群版可以有效的扩展数据规模,相比标准版支持存储量更大的64、128、256 GB 集群版,可以有效的满足数据扩展需求。 QPS 压力较大 标准版 Redis 无法支撑较大的 QPS,需要采用多节点的部署方式来冲破 Redis 单线程的性能瓶颈。 吞吐密集型应用 相比标准版,Redis 集群版的内网吞吐限制相对较低,针对热点数据读取、大吞吐类型的业务可以友好的支持。 对 Redis 协议不敏感的应用 由于集群版的架构引入了多个组件,在 Redis 协议支持上相比标准版有一定限制。

剑曼红尘 2020-04-27 14:41:57 0 浏览量 回答数 0

问题

用户指南-读写分离-读写分离简介

李沃晟 2019-12-01 21:38:38 697 浏览量 回答数 0

问题

对比ECS自建数据库与RDS性能时的注意事项

云栖大讲堂 2019-12-01 21:42:55 1114 浏览量 回答数 0

问题

如何在云数据库 MongoDB 版中创建实例

云栖大讲堂 2019-12-01 21:22:39 831 浏览量 回答数 0

问题

读写分离简介

云栖大讲堂 2019-12-01 21:39:36 1046 浏览量 回答数 0

回答

一、数据库瓶颈 不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。 1、IO瓶颈 第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表。 第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库。 2、CPU瓶颈 第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算。 第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。 结果: 每个库的结构都一样; 每个库的数据都不一样,没有交集; 所有库的并集是全量数据; 场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。 分析:库多了,io和cpu的压力自然可以成倍缓解。 2、水平分表 概念:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。 结果: 每个表的结构都一样; 每个表的数据都不一样,没有交集; 所有表的并集是全量数据; 场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。推荐:一次SQL查询优化原理分析 分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。 3、垂直分库 概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。 结果: 每个库的结构都不一样; 每个库的数据也不一样,没有交集; 所有库的并集是全量数据; 场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块。 分析:到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。 4、垂直分表 概念:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。 结果: 每个表的结构都不一样; 每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据; 所有表的并集是全量数据; 场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。 分析:可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。 但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。 三、分库分表工具 sharding-sphere:jar,前身是sharding-jdbc; TDDL:jar,Taobao Distribute Data Layer; Mycat:中间件。 注:工具的利弊,请自行调研,官网和社区优先。 四、分库分表步骤 根据容量(当前容量和增长量)评估分库或分表个数 -> 选key(均匀)-> 分表规则(hash或range等)-> 执行(一般双写)-> 扩容问题(尽量减少数据的移动)。 扩展:MySQL:分库分表与分区的区别和思考 五、分库分表问题 1、非partition key的查询问题 基于水平分库分表,拆分策略为常用的hash法。 端上除了partition key只有一个非partition key作为条件查询 映射法 基因法 注:写入时,基因法生成user_id,如图。关于xbit基因,例如要分8张表,23=8,故x取3,即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。 根据user_name查询时,先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。 端上除了partition key不止一个非partition key作为条件查询 映射法 冗余法 注:按照order_id或buyer_id查询时路由到db_o_buyer库中,按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置!有其他好的办法吗?改变技术栈呢? 后台除了partition key还有各种非partition key组合条件查询 NoSQL法 冗余法 2、非partition key跨库跨表分页查询问题 基于水平分库分表,拆分策略为常用的hash法。 注:用NoSQL法解决(ES等)。 3、扩容问题 基于水平分库分表,拆分策略为常用的hash法。 水平扩容库(升级从库法) 注:扩容是成倍的。 水平扩容表(双写迁移法) 第一步:(同步双写)修改应用配置和代码,加上双写,部署; 第二步:(同步双写)将老库中的老数据复制到新库中; 第三步:(同步双写)以老库为准校对新库中的老数据; 第四步:(同步双写)修改应用配置和代码,去掉双写,部署; 注:双写是通用方案。 六、分库分表总结 分库分表,首先得知道瓶颈在哪里,然后才能合理地拆分(分库还是分表?水平还是垂直?分几个?)。且不可为了分库分表而拆分。 选key很重要,既要考虑到拆分均匀,也要考虑到非partition key的查询。 只要能满足需求,拆分规则越简单越好。 七、分库分表示例 示例GitHub地址:https://github.com/littlecharacter4s/study-sharding 来源:cnblogs.com/littlecharacter/p/9342129.html 俩元

AA大大官 2020-03-31 12:45:48 0 浏览量 回答数 0

问题

使用表格存储的表的建议有哪些

云栖大讲堂 2019-12-01 20:57:03 1070 浏览量 回答数 0

回答

先做这样的约定:更新操作(write)是一系列顺序的过程,通过其他机制 确定更新操作的顺序(例如primary-secondary 架构中由primary 决定顺序),每个更新操作记为wi, i 为更新操作单调递增的序号,每个wi 执行成功后副本数据都发生变化,称为不同的数据版本,记 作vi。假设每个副本都保存了历史上所有版本的数据。 write-all-read-one Write-all-read-one(简称WARO)是一种最简单的副本控制规则,顾名思义即在更新时写所有 的副本,只有在所有的副本上更新成功,才认为更新成功,从而保证所有的副本一致,这样在读取 数据时可以读任一副本上的数据。 由于更新操作需要在所有的N 个副本上都成功,更新操作才能成 功,所以一旦有一个副本异常,更新操作失败,更新服务不可用。对于更新服务,虽然有N 个副本, 但系统无法容忍任何一个副本异常。另一方面,N 个副本中只要有一个副本正常,系统就可以提供 读服务。对于读服务而言,当有N 个副本时,系统可以容忍N-1 个副本异常。 从上述分析可以发现WARO 读服务的可用性较高,但更新服务的可用性不高,甚至虽然使用了 副本,但更新服务的可用性等效于没有副本。 Quorum 定义 在Quorum 机制下,当某次更新操作wi 一旦在所有N 个副本中的W 个副本上都成功,则就称 该更新操作为“成功提交的更新操作”,称对应的数据为“成功提交的数据”。令R>N-W,由于更新 操作wi 仅在W 个副本上成功,所以在读取数据时,最多需要读取R 个副本则一定能读到wi 更新后 的数据vi 。如果某次更新wi 在W 个副本上成功,由于W+R>N,任意R 个副本组成的集合一定与 成功的W个副本组成的集合有交集,所以读取R 个副本一定能读到wi 更新后的数据vi。如图 2-10, Quorum 机制的原理可以文森图表示。 某系统有5 个副本,W=3,R=3,最初5 个副本的数据一致,都是v1,某次更新操作 w2 在前3 副本上成功,副本情况变成(v2 v2 v2 v1 v1)。此时,任意3 个副本组成的集合中一定包括 v2。 在上述定义中,令W=N,R=1,就得到WARO,即WARO 是Quorum 机制的一种特例。 与分析WARO 相似,分析Quorum 机制的可用性。限制Quorum 参数为W+R=N+1。由于更新 操作需要在W 个副本上都成功,更新操作才能成功,所以一旦N-W+1 个副本异常,更新操作始终 无法在W 个副本上成功,更新服务不可用。另一方面,一旦N-R+1 个副本异常,则无法保证一定 可以读到与W 个副本有交集的副本集合,则读服务的一致性下降。 再次强调:仅仅依赖quorum 机制是无法保证强一致性的。因为仅有quorum 机制时无法确 定最新已成功提交的版本号,除非将最新已提交的版本号作为元数据由特定的元数据服务器或元数 据集群管理,否则很难确定最新成功提交的版本号。在下一节中,将讨论在哪些情况下,可以仅仅 通过quorum 机制来确定最新成功提交的版本号。 Quorum 机制的三个系统参数N、W、R 控制了系统的可用性,也是系统对用户的服务承诺:数 据最多有N 个副本,但数据更新成功W 个副本即返回用户成功。对于一致性要求较高的Quorum 系 统,系统还应该承诺任何时候不读取未成功提交的数据,即读取到的数据都是曾经在W 个副本上成 功的数据。 读取最新成功提交的数据 Quorum 机制只需成功更新N 个副本中的W 个,在读取R 个副本时,一定可以读到最新的成功 提交的数据。但由于有不成功的更新情况存在,仅仅读取R 个副本却不一定能确定哪个版本的数据 是最新的已提交的数据。对于一个强一致性Quorum 系统, 若存在个数据少于W 个,假设为X 个,则继续读取其他副本,直若成功读取到W 个 该版本的副本,则该数据为最新的成功提交的数据;如果在所有副本中该数据的个数肯定不满 足W 个,则R 中版本号第二大的为最新的成功提交的副本。 例: 在读取到(v2 v1 v1)时,继续读取剩余的副本,若读到剩余两个副本 为(v2 v2)则v2 是最新的已提交的副本;若读到剩余的两个副本为(v2 v1)或(v1 v1)则v1 是最新 成功提交的版本;若读取后续两个副本有任一超时或失败,则无法判断哪个版本是最新的成功提交 的版本。 可以看出,在单纯使用Quorum 机制时,若要确定最新的成功提交的版本,最多需要读取R+ (W-R-1)=N 个副本,当出现任一副本异常时,读最新的成功提交的版本这一功能都有可能不可用。 实际工程中,应该尽量通过其他技术手段,回避通过Quorum 机制读取最新的成功提交的版本。例 如,当quorum 机制与primary-secondary 控制协议结合使用时,可以通过读取primary 的方式读取到 最新的已提交的数据。 基于Quorum 机制选择primary副本 读取数据时依照一致性要求的不 同可以有不同的做法:如果需要强一致性的立刻读取到最新的成功提交的数据,则可以简单的只读 取primary 副本上的数据即可,也可以通过上节的方式读取;如果需要会话一致性,则可以根据之 前已经读到的数据版本号在各个副本上进行选择性读取;如果只需要弱一致性,则可以选择任意副 本读取。 在primary-secondary 协议中,当primary 异常时,需要选择出一个新的primary,之后secondary 副本与primary 同步数据。通常情况下,选择新的primary 的工作是由某一中心节点完成的,在引入 quorum 机制后,常用的primary 选择方式与读取数据的方式类似,即中心节点读取R 个副本,选择 R 个副本中版本号最高的副本作为新的primary。新primary 与至少W 个副本完成数据同步后作为新 的primary 提供读写服务。首先,R 个副本中版本号最高的副本一定蕴含了最新的成功提交的数据。 再者,虽然不能确定最高版本号的数是一个成功提交的数据,但新的primary 在随后与secondary 同 步数据,使得该版本的副本个数达到W,从而使得该版本的数据成为成功提交的数据。 例:在N=5,W=3,R=3 的系统中,某时刻副本最大版本号为(v2 v2 v1 v1 v1),此时v1 是 系统的最新的成功提交的数据,v2 是一个处于中间状态的未成功提交的数据。假设此刻原primary 副本异常,中心节点进行primary 切换工作。这类“中间态”数据究竟作为“脏数据”被删除,还 是作为新的数据被同步后成为生效的数据,完全取决于这个数据能否参与新primary 的选举。下面 分别分析这两种情况。 第一、如图 2-12,若中心节点与其中3 个副本通信成功,读取到的版本号为(v1 v1 v1),则任 选一个副本作为primary,新primary 以v1 作为最新的成功提交的版本并与其他副本同步,当与第1、 第2 个副本同步数据时,由于第1、第2 个副本版本号大于primary,属于脏数据,可以按照2.2.2.4 节中介绍的处理脏数据的方式解决。实践中,新primary 也有可能与后两个副本完成同步后就提供 数据服务,随后自身版本号也更新到v2,如果系统不能保证之后的v2 与之前的v2 完全一样,则新 primary 在与第1、2 个副本同步数据时不但要比较数据版本号还需要比较更新操作的具体内容是否 一样。 第二、若中心节点与其他3 个副本通信成功,读取到的版本号为(v2 v1 v1),则选取版本号为 v2 的副本作为新的primary,之后,一旦新primary 与其他2 个副本完成数据同步,则符合v2 的副 本个数达到W 个,成为最新的成功提交的副本,新primary 可以提供正常的读写服务。

kun坤 2020-04-24 15:56:40 0 浏览量 回答数 0

问题

全球级的分布式数据库 Google Spanner原理 热:报错

kun坤 2020-06-09 15:26:35 4 浏览量 回答数 1

问题

你们有没有做 MySQL 读写分离?如何实现 MySQL 的读写分离?【Java问答】44期

剑曼红尘 2020-06-24 08:34:06 8 浏览量 回答数 1

问题

达达O2O后台架构演进实践:从0到4000高并发请求背后的努力:报错

kun坤 2020-06-09 15:20:48 4 浏览量 回答数 1

回答

详细解答可以参考官方帮助文档 在上传任何文件到 OSS 之前,您需要首先创建存储空间以用来存储文件。存储空间具有各种配置属性,包括其地域、访问权限以及其他元数据。 操作步骤 进入OSS 管理控制台界面。 单击左侧存储空间列表中的新增按钮+,或者单击页面右上方的新建 Bucket按钮,打开新建 Bucket对话框。 在Bucket 名称框中,输入存储空间名称。 存储空间的命名必须符合命名规范。 所选定的存储空间名称在阿里云 OSS 的所有现有存储空间名称中必须具有唯一性。 创建后不支持更改存储空间名称。 有关存储空间命名的更多信息,请参阅基本概念介绍。 在区域框中,下拉选择该存储空间的数据中心。 订购后不支持更换地域。如需要通过 ECS 内网访问 OSS,需要选择与您 ECS 相同的地域。更多信息请参阅OSS访问域名使用规则。 在 存储类型 框中,下拉选择所需要的存储类型。 标准存储:高可靠、高可用、高性能,数据会经常被访问到。 低频访问:数据长期存储、较少访问,存储单价低于标准类型。低频访问存储类型的文件有最短存储时间,存储时间短于30天的文件提前删除会产生一定费用。低频访问存储文件有最小计量空间,文件大小低于64KB,会按照64KB 计算存储空间,数据获取会产生费用。 归档存储:适合需要长期保存(建议半年以上)的归档数据,在存储周期内极少被访问,数据进入到可读取状态需要等待1分钟的解冻时间。适合需要长期保存的档案数据、医疗影像、科学资料、影视素材。 在 读写权限 框中,下拉选择对应的权限。 私有:只有该存储空间的拥有者可以对该存储空间内的文件进行读写操作,其他人无法访问该存储空间内的文件。 公共读:只有该存储空间的拥有者可以对该存储空间内的文件进行写操作,任何人(包括匿名访问者)可以对该存储空间中的文件进行读操作。 公共读写:任何人(包括匿名访问者)都可以对该存储空间中的文件进行读写操作。 注意 所有这些操作产生的费用由该存储空间的拥有者承担,请慎用该权限。 单击确定。

2019-12-01 23:13:03 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 在上传任何文件到 OSS 之前,您需要首先创建存储空间以用来存储文件。存储空间具有各种配置属性,包括其地域、访问权限以及其他元数据。 操作步骤 进入OSS 管理控制台界面。 单击左侧存储空间列表中的新增按钮+,或者单击页面右上方的新建 Bucket按钮,打开新建 Bucket对话框。 在Bucket 名称框中,输入存储空间名称。 存储空间的命名必须符合命名规范。 所选定的存储空间名称在阿里云 OSS 的所有现有存储空间名称中必须具有唯一性。 创建后不支持更改存储空间名称。 有关存储空间命名的更多信息,请参阅基本概念介绍。 在区域框中,下拉选择该存储空间的数据中心。 订购后不支持更换地域。如需要通过 ECS 内网访问 OSS,需要选择与您 ECS 相同的地域。更多信息请参阅OSS访问域名使用规则。 在 存储类型 框中,下拉选择所需要的存储类型。 标准存储:高可靠、高可用、高性能,数据会经常被访问到。 低频访问:数据长期存储、较少访问,存储单价低于标准类型。低频访问存储类型的文件有最短存储时间,存储时间短于30天的文件提前删除会产生一定费用。低频访问存储文件有最小计量空间,文件大小低于64KB,会按照64KB 计算存储空间,数据获取会产生费用。 归档存储:适合需要长期保存(建议半年以上)的归档数据,在存储周期内极少被访问,数据进入到可读取状态需要等待1分钟的解冻时间。适合需要长期保存的档案数据、医疗影像、科学资料、影视素材。 在 读写权限 框中,下拉选择对应的权限。 私有:只有该存储空间的拥有者可以对该存储空间内的文件进行读写操作,其他人无法访问该存储空间内的文件。 公共读:只有该存储空间的拥有者可以对该存储空间内的文件进行写操作,任何人(包括匿名访问者)可以对该存储空间中的文件进行读操作。 公共读写:任何人(包括匿名访问者)都可以对该存储空间中的文件进行读写操作。 注意 所有这些操作产生的费用由该存储空间的拥有者承担,请慎用该权限。 单击确定。

2019-12-01 23:13:03 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 在上传任何文件到 OSS 之前,您需要首先创建存储空间以用来存储文件。存储空间具有各种配置属性,包括其地域、访问权限以及其他元数据。 操作步骤 进入OSS 管理控制台界面。 单击左侧存储空间列表中的新增按钮+,或者单击页面右上方的新建 Bucket按钮,打开新建 Bucket对话框。 在Bucket 名称框中,输入存储空间名称。 存储空间的命名必须符合命名规范。 所选定的存储空间名称在阿里云 OSS 的所有现有存储空间名称中必须具有唯一性。 创建后不支持更改存储空间名称。 有关存储空间命名的更多信息,请参阅基本概念介绍。 在区域框中,下拉选择该存储空间的数据中心。 订购后不支持更换地域。如需要通过 ECS 内网访问 OSS,需要选择与您 ECS 相同的地域。更多信息请参阅OSS访问域名使用规则。 在 存储类型 框中,下拉选择所需要的存储类型。 标准存储:高可靠、高可用、高性能,数据会经常被访问到。 低频访问:数据长期存储、较少访问,存储单价低于标准类型。低频访问存储类型的文件有最短存储时间,存储时间短于30天的文件提前删除会产生一定费用。低频访问存储文件有最小计量空间,文件大小低于64KB,会按照64KB 计算存储空间,数据获取会产生费用。 归档存储:适合需要长期保存(建议半年以上)的归档数据,在存储周期内极少被访问,数据进入到可读取状态需要等待1分钟的解冻时间。适合需要长期保存的档案数据、医疗影像、科学资料、影视素材。 在 读写权限 框中,下拉选择对应的权限。 私有:只有该存储空间的拥有者可以对该存储空间内的文件进行读写操作,其他人无法访问该存储空间内的文件。 公共读:只有该存储空间的拥有者可以对该存储空间内的文件进行写操作,任何人(包括匿名访问者)可以对该存储空间中的文件进行读操作。 公共读写:任何人(包括匿名访问者)都可以对该存储空间中的文件进行读写操作。 注意 所有这些操作产生的费用由该存储空间的拥有者承担,请慎用该权限。 单击确定。

2019-12-01 23:13:03 0 浏览量 回答数 0

回答

1.阻塞与同步2.BIO与NIO对比3.NIO简介4.缓冲区Buffer5.通道Channel6.反应堆7.选择器8.NIO源码分析9.AIO1.阻塞与同步1)阻塞(Block)和非租塞(NonBlock):阻塞和非阻塞是进程在访问数据的时候,数据是否准备就绪的一种处理方式,当数据没有准备的时候阻塞:往往需要等待缞冲区中的数据准备好过后才处理其他的事情,否則一直等待在那里。非阻塞:当我们的进程访问我们的数据缓冲区的时候,如果数据没有准备好则直接返回,不会等待。如果数据已经准备好,也直接返回2)同步(Synchronization)和异步(Async)的方式:同步和异步都是基于应用程序私操作系统处理IO事件所采用的方式,比如同步:是应用程序要直接参与IO读写的操作。异步:所有的IO读写交给搡作系统去处理,应用程序只需要等待通知。同步方式在处理IO事件的时候,必须阻塞在某个方法上靣等待我们的IO事件完成(阻塞IO事件或者通过轮询IO事件的方式).对于异步来说,所有的IO读写都交给了搡作系统。这个时候,我们可以去做其他的事情,并不拓要去完成真正的IO搡作,当搡作完成IO后.会给我们的应用程序一个通知同步:阻塞到IO事件,阻塞到read成则write。这个时候我们就完全不能做自己的事情,让读写方法加入到线程里面,然后阻塞线程来实现,对线程的性能开销比较大,参考:https://blog.csdn.net/CharJay_Lin/article/details/812598802.BIO与NIO对比block IO与Non-block IO1)区别IO模型 IO NIO方式 从硬盘到内存 从内存到硬盘通信 面向流(乡村公路) 面向缓存(高速公路,多路复用技术)处理 阻塞IO(多线程) 非阻塞IO(反应堆Reactor)触发 无 选择器(轮询机制)2)面向流与面向缓冲Java NIO和IO之间第一个最大的区别是,IO是面向流的.NIO是面向缓冲区的。Java IO面向流意味着毎次从流中读一个成多个字节,直至读取所有字节,它们没有被缓存在任何地方,此外,它不能前后移动流中的数据。如果需要前后移动从流中读取的教据,需要先将它缓存到一个缓冲区。Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区,霱要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是,还需要检查是否该缓冲区中包含所有您需要处理的数裾。而且,需确保当更多的数据读入缓冲区时,不要覆盖缓冲区里尚未处理的数据。3)阻塞与非阻塞Java IO的各种流是阻塞的。这意味着,当一个线程调用read() 或 write()时,该线程被阻塞,直到有一些数据被读取,或数据完全写入。该线程在此期间不能再干任何事情了。 Java NIO的非阻塞模式,使一个线程从某通道发送请求读取数据,但是它仅能得到目前可用的数据,如果目前没有数据可用时,就什么都不会获取。而不是保持线程阻塞,所以直至数据变的可以读取之前,该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道,但不需要等待它完全写入,这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作,所以一个单独的线程现在可以管理多个输入和输出通道(channel)。4)选择器(Selector)Java NIO的选择器允许一个单独的线程来监视多个输入通道,你可以注册多个通道使用一个选择器,然后使用一个单独的线程来“选择"通道:这些通里已经有可以处理的褕入,或者选择已准备写入的通道。这选怿机制,使得一个单独的线程很容易来管理多个通道。5)NIO和BIO读取文件BIO读取文件:链接BIO从一个阻塞的流中一行一行的读取数据image | left | 469x426NIO读取文件:链接通道是数据的载体,buffer是存储数据的地方,线程每次从buffer检查数据通知给通道image | left | 559x3946)处理数据的线程数NIO:一个线程管理多个连接BIO:一个线程管理一个连接3.NIO简介在Java1.4之前的I/O系统中,提供的都是面向流的I/O系统,系统一次一个字节地处理数据,一个输入流产生一个字节的数据,一个输出流消费一个字节的数据,面向流的I/O速度非常慢,而在Java 1.4中推出了NIO,这是一个面向块的I/O系统,系统以块的方式处理处理,每一个操作在一步中产生或者消费一个数据库,按块处理要比按字节处理数据快的多。在NIO中有几个核心对象需要掌握:缓冲区(Buffer)、通道(Channel)、选择器(Selector)。参考:链接image2.png | center | 851x3834.缓冲区Buffer缓冲区实际上是一个容器对象,更直接的说,其实就是一个数组,在NIO库中,所有数据都是用缓冲区处理的。在读取数据时,它是直接读到缓冲区中的; 在写入数据时,它也是写入到缓冲区中的;任何时候访问 NIO 中的数据,都是将它放到缓冲区中。而在面向流I/O系统中,所有数据都是直接写入或者直接将数据读取到Stream对象中。在NIO中,所有的缓冲区类型都继承于抽象类Buffer,最常用的就是ByteBuffer,对于Java中的基本类型,基本都有一个具体Buffer类型与之相对应,它们之间的继承关系如下图所示:image3.png | center | 650x3681)其中的四个属性的含义分别如下:容量(Capacity):缓冲区能够容纳的数据元素的最大数量。这一个容量在缓冲区创建时被设定,并且永远不能改变。上界(Limit):缓冲区的第一个不能被读或写的元素。或者说,缓冲区中现存元素的计数。位置(Position):下一个要被读或写的元素的索引。位置会自动由相应的 get( )和 put( )函数更新。标记(Mark):下一个要被读或写的元素的索引。位置会自动由相应的 get( )和 put( )函数更新。2)Buffer的常见方法如下所示:flip(): 写模式转换成读模式rewind():将 position 重置为 0 ,一般用于重复读。clear() :compact(): 将未读取的数据拷贝到 buffer 的头部位。mark(): reset():mark 可以标记一个位置, reset 可以重置到该位置。Buffer 常见类型: ByteBuffer 、 MappedByteBuffer 、 CharBuffer 、 DoubleBuffer 、 FloatBuffer 、 IntBuffer 、 LongBuffer 、 ShortBuffer 。3)基本操作Buffer基础操作: 链接缓冲区分片,缓冲区分配,直接缓存区,缓存区映射,缓存区只读:链接4)缓冲区存取数据流程存数据时position会++,当停止数据读取的时候调用flip(),此时limit=position,position=0读取数据时position++,一直读取到limitclear() 清空 buffer ,准备再次被写入 (position 变成 0 , limit 变成 capacity) 。5.通道Channel通道是一个对象,通过它可以读取和写入数据,当然了所有数据都通过Buffer对象来处理。我们永远不会将字节直接写入通道中,相反是将数据写入包含一个或者多个字节的缓冲区。同样不会直接从通道中读取字节,而是将数据从通道读入缓冲区,再从缓冲区获取这个字节。image4.png | center | 368x191在NIO中,提供了多种通道对象,而所有的通道对象都实现了Channel接口。它们之间的继承关系如下图所示:image5.png | center | 650x5171)使用NIO读取数据在前面我们说过,任何时候读取数据,都不是直接从通道读取,而是从通道读取到缓冲区。所以使用NIO读取数据可以分为下面三个步骤:从FileInputStream获取Channel 创建Buffer 将数据从Channel读取到Buffer中 例子:链接 2)使用NIO写入数据使用NIO写入数据与读取数据的过程类似,同样数据不是直接写入通道,而是写入缓冲区,可以分为下面三个步骤:从FileInputStream获取Channel 创建Buffer 将数据从Channel写入到Buffer中 例子:链接 6.反应堆1)阻塞IO模型在老的IO包中,serverSocket和socket都是阻塞式的,因此一旦有大规模的并发行为,而每一个访问都会开启一个新线程。这时会有大规模的线程上下文切换操作(因为都在等待,所以资源全都被已有的线程吃掉了),这时无论是等待的线程还是正在处理的线程,响应率都会下降,并且会影响新的线程。image6.png | center | 739x3362)NIOJava NIO是在jdk1.4开始使用的,它既可以说成“新IO”,也可以说成非阻塞式I/O。下面是java NIO的工作原理:1.由一个专门的线程来处理所有的IO事件,并负责分发。2.事件驱动机制:事件到的时候触发,而不是同步的去监视事件。3.线程通讯:线程之间通过wait,notify等方式通讯。保证每次上下文切换都是有意义的。减少无谓的线程切换。image7.png | center | 689x251注:每个线程的处理流程大概都是读取数据,解码,计算处理,编码,发送响应。7.选择器传统的 server / client 模式会基于 TPR ( Thread per Request ) .服务器会为每个客户端请求建立一个线程.由该线程单独负贵处理一个客户请求。这种模式带未的一个问题就是线程数是的剧增.大量的线程会增大服务器的开销,大多数的实现为了避免这个问题,都采用了线程池模型,并设置线程池线程的最大数量,这又带来了新的问题,如果线程池中有 200 个线程,而有 200 个用户都在进行大文件下载,会导致第 201 个用户的请求无法及时处理,即便第 201 个用户只想请求一个几 KB 大小的页面。传统的 Sorvor / Client 模式如下围所示:image8.png | center | 597x286NIO 中非阻塞IO采用了基于Reactor模式的工作方式,IO调用不会被阻塞,相反是注册感兴趣的特点IO事件,如可读数据到达,新的套接字等等,在发生持定率件时,系统再通知我们。 NlO中实现非阻塞IO的核心设计Selector,Selector就是注册各种IO事件的地方,而且当那些事件发生时,就是这个对象告诉我们所发生的事件。image9.png | center | 462x408当有读或者写等任何注册的事件发生时,可以从Selector中获得相应的SelectionKey,同时从SelectionKey中可以找到发生的事件和该事件所发生的具体的SelectableChannel,以获得客户端发送过来的数据。使用NIO中非阻塞IO编写服务器处理程序,有三个步骤1.向Selector对象注册感兴趣的事件2.从Selector中获取感兴趣的事件3.根据不同事件进行相应的处理8.NIO源码分析Selector是NIO的核心epool模型1)SelectorSelector的open()方法:链接2)ServerSocketChannelServerSocketChannel.open() 链接9.AIOAsynchronous IO异步非阻塞IOBIO ServerSocketNIO ServerSocketChannelAIO AsynchronousServerSocketChannel

wangccsy 2019-12-02 01:46:51 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 应用场景 在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法抵抗读取压力,甚至对主业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以在某个地域中创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,以此增加应用的吞吐量。 简介 创建只读实例相当于复制了一个主实例,数据与主实例一致,主实例的数据更新也会通过MySQL的原生复制功能自动同步到所有只读实例。网络类型不同的主实例和只读实例之间也可以进行数据同步。只读实例跟主实例在同一地域,但可以在不同的可用区。只读实例拓扑图如下图所示: 注意 目前,云数据库RDS的以下版本支持只读实例:MySQL 5.6、MySQL 5.7(不包括MySQL 5.7基础版)。 只读实例为单个物理节点的架构(没有备节点)。 计费标准 只读实例需要额外收费,其计费方式是按时付费,费用详情请参见云数据库RDS详细价格信息中的只读实例部分。 功能特点 规格可以与主实例不一致,并可以随时更改规格(没有时间限制),便于弹性升降级。 支持按时计费,使用更灵活,费用更便宜。 不需要维护账号与数据库,全部通过主实例同步。 具有独立的白名单配置。 提供近20个系统性能指标的监控视图,如磁盘容量、IOPS、连接数、CPU利用率、网络流量等。 提供多种优化建议,如存储引擎检查、主键检查、大表检查、索引偏多、缺失索引等,用户可以根据优化建议并结合自身的应用特点来对数据库进行优化。 功能限制 只读实例有如下功能限制: 如果主实例规格内存大于等于64G,则最多允许创建10个只读实例。 如果主实例规格内存小于64G,则最多允许创建5个只读实例。 备份设置:不支持备份设置以及临时备份。 实例恢复: 不支持通过备份文件或任意时间点创建临时实例,不支持通过备份集覆盖实例。 创建只读实例后,主实例将不支持通过备份集直接覆盖实例来恢复数据。 数据迁移:不支持将数据迁移至只读实例。 数据库管理:不支持创建和删除数据库。 账号管理:不支持创建和删除账号,不支持为账号授权以及修改账号密码功能。

2019-12-01 22:57:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 应用场景 在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法抵抗读取压力,甚至对主业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以在某个地域中创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,以此增加应用的吞吐量。 简介 创建只读实例相当于复制了一个主实例,数据与主实例一致,主实例的数据更新也会通过MySQL的原生复制功能自动同步到所有只读实例。网络类型不同的主实例和只读实例之间也可以进行数据同步。只读实例跟主实例在同一地域,但可以在不同的可用区。只读实例拓扑图如下图所示: 注意 目前,云数据库RDS的以下版本支持只读实例:MySQL 5.6、MySQL 5.7(不包括MySQL 5.7基础版)。 只读实例为单个物理节点的架构(没有备节点)。 计费标准 只读实例需要额外收费,其计费方式是按时付费,费用详情请参见云数据库RDS详细价格信息中的只读实例部分。 功能特点 规格可以与主实例不一致,并可以随时更改规格(没有时间限制),便于弹性升降级。 支持按时计费,使用更灵活,费用更便宜。 不需要维护账号与数据库,全部通过主实例同步。 具有独立的白名单配置。 提供近20个系统性能指标的监控视图,如磁盘容量、IOPS、连接数、CPU利用率、网络流量等。 提供多种优化建议,如存储引擎检查、主键检查、大表检查、索引偏多、缺失索引等,用户可以根据优化建议并结合自身的应用特点来对数据库进行优化。 功能限制 只读实例有如下功能限制: 如果主实例规格内存大于等于64G,则最多允许创建10个只读实例。 如果主实例规格内存小于64G,则最多允许创建5个只读实例。 备份设置:不支持备份设置以及临时备份。 实例恢复: 不支持通过备份文件或任意时间点创建临时实例,不支持通过备份集覆盖实例。 创建只读实例后,主实例将不支持通过备份集直接覆盖实例来恢复数据。 数据迁移:不支持将数据迁移至只读实例。 数据库管理:不支持创建和删除数据库。 账号管理:不支持创建和删除账号,不支持为账号授权以及修改账号密码功能。

2019-12-01 22:57:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 应用场景 在对数据库有少量写请求,但有大量读请求的应用场景下,单个实例可能无法抵抗读取压力,甚至对主业务产生影响。为了实现读取能力的弹性扩展,分担数据库压力,您可以在某个地域中创建一个或多个只读实例,利用只读实例满足大量的数据库读取需求,以此增加应用的吞吐量。 简介 创建只读实例相当于复制了一个主实例,数据与主实例一致,主实例的数据更新也会通过MySQL的原生复制功能自动同步到所有只读实例。网络类型不同的主实例和只读实例之间也可以进行数据同步。只读实例跟主实例在同一地域,但可以在不同的可用区。只读实例拓扑图如下图所示: 注意 目前,云数据库RDS的以下版本支持只读实例:MySQL 5.6、MySQL 5.7(不包括MySQL 5.7基础版)。 只读实例为单个物理节点的架构(没有备节点)。 计费标准 只读实例需要额外收费,其计费方式是按时付费,费用详情请参见云数据库RDS详细价格信息中的只读实例部分。 功能特点 规格可以与主实例不一致,并可以随时更改规格(没有时间限制),便于弹性升降级。 支持按时计费,使用更灵活,费用更便宜。 不需要维护账号与数据库,全部通过主实例同步。 具有独立的白名单配置。 提供近20个系统性能指标的监控视图,如磁盘容量、IOPS、连接数、CPU利用率、网络流量等。 提供多种优化建议,如存储引擎检查、主键检查、大表检查、索引偏多、缺失索引等,用户可以根据优化建议并结合自身的应用特点来对数据库进行优化。 功能限制 只读实例有如下功能限制: 如果主实例规格内存大于等于64G,则最多允许创建10个只读实例。 如果主实例规格内存小于64G,则最多允许创建5个只读实例。 备份设置:不支持备份设置以及临时备份。 实例恢复: 不支持通过备份文件或任意时间点创建临时实例,不支持通过备份集覆盖实例。 创建只读实例后,主实例将不支持通过备份集直接覆盖实例来恢复数据。 数据迁移:不支持将数据迁移至只读实例。 数据库管理:不支持创建和删除数据库。 账号管理:不支持创建和删除账号,不支持为账号授权以及修改账号密码功能。

2019-12-01 22:57:11 0 浏览量 回答数 0

问题

【archsummit 回顾】阿里云章文嵩:构建大型云计算平台分布式技术的实践

云课堂 2019-12-01 21:03:36 14448 浏览量 回答数 9

问题

如何设计一个高并发系统?【Java问答学堂】45期

剑曼红尘 2020-06-28 20:53:14 10 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站