单端同步是什么

数据可靠性RocketMQ支持异步实时刷盘，同步刷盘，同步Replication，异步ReplicationKafka使用异步刷盘方式，异步Replication/同步Replication总结：RocketMQ的同步刷盘在单机可靠性上比Kafka更高，不会因为操作系统Crash，导致数据丢失。Kafka同步Replication理论上性能低于RocketMQ的同步Replication，原因是Kafka的数据以分区为单位组织，意味着一个Kafka实例上会有几百个数据分区，RocketMQ一个实例上只有一个数据分区，RocketMQ可以充分利用IO Group Commit机制，批量传输数据，配置同步Replication与异步Replication相比，性能损耗约20%~30%，Kafka没有亲自测试过，但是个人认为理论上会低于RocketMQ。性能对比Kafka单机写入TPS约在百万条/秒，消息大小10个字节RocketMQ单机写入TPS单实例约7万条/秒，单机部署3个Broker，可以跑到最高12万条/秒，消息大小10个字节总结：Kafka的TPS跑到单机百万，主要是由于Producer端将多个小消息合并，批量发向Broker。RocketMQ为什么没有这么做？Producer通常使用Java语言，缓存过多消息，GC是个很严重的问题Producer调用发送消息接口，消息未发送到Broker，向业务返回成功，此时Producer宕机，会导致消息丢失，业务出错Producer通常为分布式系统，且每台机器都是多线程发送，我们认为线上的系统单个Producer每秒产生的数据量有限，不可能上万。缓存的功能完全可以由上层业务完成。单机支持的队列数Kafka单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长。Kafka分区数无法过多的问题RocketMQ单机支持最高5万个队列，Load不会发生明显变化队列多有什么好处？单机可以创建更多Topic，因为每个Topic都是由一批队列组成Consumer的集群规模和队列数成正比，队列越多，Consumer集群可以越大消息投递实时性Kafka使用短轮询方式，实时性取决于轮询间隔时间，0.8以后版本支持长轮询。RocketMQ使用长轮询，同Push方式实时性一致，消息的投递延时通常在几个毫秒。消费失败重试Kafka消费失败不支持重试。RocketMQ消费失败支持定时重试，每次重试间隔时间顺延总结：例如充值类应用，当前时刻调用运营商网关，充值失败，可能是对方压力过多，稍后再调用就会成功，如支付宝到银行扣款也是类似需求。这里的重试需要可靠的重试，即失败重试的消息不因为Consumer宕机导致丢失。严格的消息顺序Kafka支持消息顺序，但是一台Broker宕机后，就会产生消息乱序RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，发送消息会失败，但是不会乱序Mysql Binlog分发需要严格的消息顺序定时消息Kafka不支持定时消息RocketMQ支持两类定时消息开源版本RocketMQ仅支持定时Level，定时Level用户可定制阿里云ONS支持定时Level，以及指定的毫秒级别的延时时间分布式事务消息Kafka不支持分布式事务消息阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也有计划支持分布式事务消息消息查询Kafka不支持消息查询RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，例如指定为订单Id）总结：消息查询对于定位消息丢失问题非常有帮助，例如某个订单处理失败，是消息没收到还是收到处理出错了。消息回溯Kafka理论上可以按照Offset来回溯消息RocketMQ支持按照时间来回溯消息，精度毫秒，例如从一天之前的某时某分某秒开始重新消费消息总结：典型业务场景如consumer做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。消费并行度Kafka的消费并行度依赖Topic配置的分区数，如分区数为10，那么最多10台机器来并行消费（每台机器只能开启一个线程），或者一台机器消费（10个线程并行消费）。即消费并行度和分区数一致。RocketMQ消费并行度分两种情况顺序消费方式并行度同Kafka完全一致乱序方式并行度取决于Consumer的线程数，如Topic配置10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。消息轨迹Kafka不支持消息轨迹阿里云ONS支持消息轨迹开发语言友好性Kafka采用Scala编写RocketMQ采用Java语言编写Broker端消息过滤Kafka不支持Broker端的消息过滤RocketMQ支持两种Broker端消息过滤方式根据Message Tag来过滤，相当于子topic概念向服务器上传一段Java代码，可以对消息做任意形式的过滤，甚至可以做Message Body的过滤拆分。消息堆积能力理论上Kafka要比RocketMQ的堆积能力更强，不过RocketMQ单机也可以支持亿级的消息堆积能力，我们认为这个堆积能力已经完全可以满足业务需求。开源社区活跃度Kafka社区更新较慢RocketMQ的github社区有250个个人、公司用户登记了联系方式，QQ群超过1000人。成熟度Kafka在日志领域比较成熟RocketMQ在阿里集团内部有大量的应用在使用，每天都产生海量的消息，并且顺利支持了多次天猫双十一海量消息考验，是数据削峰填谷的利器。

我们究竟想要分布式存储如何样的一致性？ 理想模型：所有的操作就像单机一样服务端使用磁盘存储服务端一次只执行一次客户端操作（即使并发）读始终是最新的写入结果（即使服务器重启或崩溃） 因此，假设有几个场景c1和c2是并发写。在写完成后，发起C3和C4读取。那么会得到什么结果？ 答案：可能是1或者是2，但是两个读都应该是相同的值返回（强一致性模型），但是单机无法做到好的容错。在现实分布式系统中肯定存在副本。 为了容错而产生的复制，让强一致性变得棘手。多副本同步写入，势必带来的是性能影响。性能/一致性之间需要取舍 ####一个简单的场景：两台副本服务器、S1和S2，客户端先发起并行写操作，然后立即读取。

回 楼主(freesoul) 的帖子 亲你的帐号是什么,看你的描述 应该是客户端配置了POP模式,并且设置了XX天后从服务端删除之前的邮件, 这样的话你每过一天,那么14天的邮件就会自动删除,就会一天天减少,建议你看一下你的客户端设置里面,改一下设置吧. ------------------------- 回 2楼(freesoul) 的帖子 亲,这个是日志,你自己看一下是不是你自己配置 的在用的,看一下IP是不是你们自己的. 并且我查询每天都有在删除的,这个肯定是POP配置导致的删除.这个一般在客户端上都有一个在服务器保留邮件备份的设置项的.你可以看一下. ------------------------- 回 4楼(freesoul) 的帖子 你用的是阿里云WINDOWS PHONE手机吗?这个我还真没有研究过,应该是只支持pop或者imap的,上面应该会有一个设置的,一般都会有的.高级设置里面有. ------------------------- 回 6楼(南希喵) 的帖子 你应该都收到本地了亲,服务端的做了彻底删除的话,我们这里也没有,恢复不了的噢.你把电脑上的备份一下,可以直接通过OUTLOOK挂载查看. ------------------------- 回 8楼(南希喵) 的帖子 客户端里面的其它设置里面有一个-高级-高级里面有一个在服务器上保留邮件备份,在前多面打钩,下面还有一个多少天后删除服务器上的邮件,这个钩去掉,可以看一下我的截图 ,操作一下,谢谢!foxmail与OUTLOOK的二个截图 ------------------------- 回 10楼(南希喵) 的帖子 可以的亲,IMAP是与网页同步的,配置好就可以用了,不需要单独设置.

是的，网站的文件在3台服务器上都需要存储，并且保证其一致性。 关于SLB是什么，简单解释如下： SLB是Server Load Balance（负载均衡）的简称，阿里云计算有限公司提供的负载均衡服务，通过设置虚拟服务IP，将位于同一机房的多台云服务器资源虚拟成一个高性能、高可用的应用服务池；再根据应用特性，将来自客户端的网络请求分发到云服务池中。 基于此，不论是带宽资源还是计算资源，通过负载均衡对外提供服务时，是将负载均衡下面的多台云服务器的资源相加后对外提供高可用性、高冗余、避免单点故障，增强系统对外服务能力的一种应用。 更多建议通过这里了解： http://help.aliyun.com/manual?spm=0.0.0.44.8fb5ec&lastSortId=335 关于如何实现服务器间数据同步的问题，可以参考这里： http://bbs.aliyun.com/read.php?tid=50969

2014年12月第2周 1）SLB植入cookie和SLB重写cookie有什么区别？ cookie植入，表示直接由SLB系统来分配和管理对客户端进行的cookie植入操作，用户在进行配置时 需要指定会话保持的超时时间； cookie重写，表示SLB系统会根据用户自定义cookie名称来分配和管理对客户端进行的cookie植入操 作，便于用户识别和区分自定义的cookie名称 http://help.aliyun.com/doc/view/13510025.html?spm=0.0.0.0.vwbsGF 2）SLB有没有对外提供API接口，因为我想做到用程序自动去控制SLB的操作？ SLB api您可以参考http://help.aliyun.com/view/13621674.html? spm=5176.7114037.1996646101.1.9RoTFM&pos=1 3）使用slb怎么实现数据的单向同步和双向同步？ 单向同步可以使用rsync，双向同步的话rsync需要借用别的服务来实现,如unison+inotify。 4）slb的vip是否可以实现远程登录？ slb 的vip无法实现远程登录。 5）slb的带宽是所有后端ECS服务器的带宽总和吗? 不是，使您购买的slb实例带宽。 6）slb健康检查机制是什么？ 用户开启健康检查功能后，当后端某个ECS健康检查出现问题时会将请求转发到其他健康检查正常的 ECS上，而当该ECS恢复正常运行时，SLB会将其自动恢复到对外或对内的服务中。 针对7层（HTTP协议）服务，SLB系统的健康检查机制为：默认通过SLB的后端系统来向该ECS应用服务 器配置的缺省首页发起http head请求（缺省通过在服务监听配置中指定的后端ECS端口进行访问）， 返回200 OK后将视为后端ECS运行正常，否则视为后端ECS运行异常。如果用户用来进行健康检查的页 面并不是应用服务器的缺省首页，那么需要用户指定相应的URI。如果用户对http head请求限定了 host字段的参数，那么需要用户指定相应的URL。用户也可以通过设定健康检查的频率、健康阈值和 不健康阈值来更好的控制健康检查功能。 针对4层（TCP协议）服务，SLB系统的健康检查机制为：默认通过在服务监听配置中指定的后端ECS端 口发起访问请求，如果端口访问正常则视为后端ECS运行正常，否则视为后端ECS运行异常。 当用户后端ECS健康检查异常后，SLB系统会将该ECS的转发权重设置为0，从而确保新的连接不会再被 转发到该ECS上，而已经建立的连接的请求却不会被直接断掉。 针对可能引起健康检查异常的排查思路点击这里查看。 关于健康检查的参数配置，提供如下参考建议： 响应超时时间：5秒 健康检查间隔：2秒 不健康阈值：3 健康阈值：3 7）权重设置为0怎么办？ 权重为0的服务器将无法提供服务。 ８）健康检查异常的排查思路？ 参考http://help.aliyun.com/doc/view/13510029.html?spm=0.0.0.0.Oa9Ezv ------------------------- 12月份第3周1）轮询与最小连接数方式的区别是什么？当前SLB支持轮询和最小连接数2种模式的转发规则。“轮询模式”会将外部和内部的访问请求依序分发给后端ECS进行处理，而“最小连接数模式”会将外部和内部的访问请求分发给当前连接数最小的一台后端ECS进行处理。2）SLB支持redis的主备？目前我们的SLB不支持主备模式（冷备），只支持"轮询"和"最小连接数"两种负载模式。关于SLB的原理您可以参阅如下博文：http://blog.aliyun.com/149 基于ECS的redis搭建，您可以参阅论坛中其它用户的分享案例：http://bbs.aliyun.com/read/161389.html3）负载均衡的多台服务器之间文件会不会自动同步？slb是不会自动同步的，需要您自行配置。4）四层和七层检查的区别是什么？如果是4层（TCP）配置，健康检查只是简单的TCP握手，不会真正去访问您的业务。但对于7层（HTTP）配置，会发HTTP请求（类似于正常访问），并根据返回状态码判断服务状态（2XX表示服务正常）。5）我有多个slb，之前一个slb由于被攻击被黑洞给屏蔽了外部请求，是否可以在slb 并屏蔽后 能够自动将请求分发到另外的slb？由于攻击导致屏蔽外部请求的话，slb没有自动切换的方法的。6）目前slb是否可以设置黑名单?暂不支持。7）我的slb实例控制台显示是停止，为什么？需要给监听的端口设置带宽才能正常。  8）我使用了 SLB那么ESC 需要购买带宽吗？不需要的。但如需要管理ECS，则可购买少些的带宽如1M来管理。9）slb变更计费方式需要多久才能生效？变更和计费将在第二日零点后生效。10）私网SLB的使用，是如何收费的呢？私网slb是不收取费用的。 ------------------------- 12月第4周1）最近用slb后打开网页老出现503 和504错误？一般都是从ECS获取站点信息等异常导致的。您首先先确保源站都可以正常的访问。2）slb检查时突然发现SLB监听错误，怎么回事？配置的健康检查的域名为空，检查的路径是/index.html，目前查看服务器中只有站点c绑定了空主机头，且站点目录下有index.html，而此站点是停止状态，现已帮您启用，查看服务器的健康检查状态已经正常。3）我想使用slb搭建一个负载均衡，后端使用windows服务器，想咨询一下后端服务器是否需要进行什么特别配置呢？另外使用了slb后，后端还能否得到用户的真实IP地址呢，要不要进行什么特殊配置才可以得到后端用户的真实IP。后端服务器的操作系统和web环境最好保持一致，硬件配置上没有什么特别的，4层tcp是可以直接获得前端用户访问的真实地址的，7层http需要在后端web服务端设置一下，参考http://help.aliyun.com/view/13502961.html?spm=5176.7114037.1996646101.1.oRpnOM&pos=14）slb支持https吗？slb您可以通过TCP协议配置443端口的方式来实现，但是安全证书需要保存在您的后端ECS上。5）健康检查后续是否提供多个域名？健康检查只支持一个域名。6）我想关闭负载均衡的健康检查，请问如何配置？4层tcp是无法关闭健康检查的，7层http可以在控制台关闭。健康检查是不会消耗您服务器的资源的，因为slb都是通过内网ip来进行健康检查。7）如何在BLS上 限制单个IP 禁止访问 我的网站呢？SLB暂时不支持设置屏蔽用户端IP。 ------------------------- Re:Re负载均衡SLB常见咨询问题（持续连载） 引用第2楼517449116于2014-12-17 15:54发表的 Re负载均衡SLB常见咨询问题（持续连载） : 如果开启健康检查，健康检查异常的话，是不是就不会给这个异常的ECS分发？ [url=http://bbs.aliyun.com/job.php?action=topost&tid=188736&pid=596806][/url] 异常的话不会在分发。 ------------------------- 2015年1月第1周1）有2台ECS起名叫A和B做SLB，A权重设的100 B权重设的0.请问.当A死机时,SLB是否会转到权重是0的B上?如果有一台设置为0，永远都不会有请求转发到此服务器上，即使权重100的宕机也不会转发到0权重的。2）会话保持的选择？开启会话保持功能后，SLB会把来自同一客户端的访问请求分发到同一台后端ECS上进行处理。针对7层（HTTP协议）服务，SLB系统是基于cookie的会话保持。针对4层（TCP协议）服务，SLB系统是基于IP地址的会话保持。3）用nagios或zabbix监控网络带宽，是否可以监控 slb的流量？nagios或zabbix，cacti是要要被监控端安装snmp或者相关agent ，slb不支持安装这些，所以无法通过这条监控软件进行监控。您可以在slb的控制台里面进行查看流量等相关信息。4）用了负载均衡后升级带宽，是不是只用在负载上面升级就可以了，ECS是不是不用在升级了？SLB与后端服务器是经过内网通信，所以如果业务量增加，您对SLB的带宽调整就行，不需要对服务器ECS进行带宽的升级。 ------------------------- 2015年1月第2周 1）SLB到期之后，会对SLB有关联的云主机怎么处理？云主机还没到期的前提下  我想把网站域名解析到SLB上 如果SLB到期了 会影响到我的网站服务么？ 云服务器是不会有什么影响的，会自动又变成单独的云服务器可以供您使用的。但是如果您的域名是解析到SLB上，那么会影响到您的站点访问的。服务器上不会有其他的问题感谢您的支持。 2)当SLB 状态为停止的时候 还计算费用吗？停止后公网slb会收取实例费用。SLB价格总览参考：http://help.aliyun.com/view/11108234_13502923.html?spm=0.0.0.0.kBLsVA 3)做了SLB负载均衡，四层和7层负载均衡是否都走slb带宽？ 都走slb带宽。 4)我想 移除 slb下的ecs（用作其他用途），请问在移除的时候是否会影响被负载到这台 ecs上的服务的使用 ，也是说slb这是是怎么处理的？ 您可以将要移除的主机的权重更改为0 ，这样默认就不会在分发到权重为0的主机上，这个时候您可以移除该主机。但要确保您的另外一台服务器可以承受所有的访问。 5)SLB实例如何释放? 您需要登录管理控制台点击负载均衡。查询您之前创建的实例在哪个节点下，然后释放您的实例。 6)SLB按照小时的带宽计费， 是否需要每小时调整？比如我可否按照一个比较高的上限， 比如3G,然后每个小时按照该小时的峰值进行独立计费呢？   在一个自然日内，限制用户变更计费方式的次数为1次，变更计费方式将在第二日零点后生效；比如用户在今天5月5日的10:00提交了变更计费方式，那么该变配申请将在明天5月6日00:00后生效。http://help.aliyun.com/view/13502923.html?spm=5176.7114037.1996646101.3.67L5dm&pos=2;SLB目前最大带宽是1000Mbps 7）SLB可以限制每个ip的访问频率吗?(工单1F684MN)slb不支持这样配置的。 8）为什么我设置SLB健康检查间隔为5S，但却每秒都有很多请求？因为用于健康检查的服务ip不止一个，每秒中都会有不同的内网ip进行健康检查，健康检查是通过内网方式，不会消耗您后端服务器的资源，您可以将健康检查间隔阈值跳大些，这样监测频率会降低很多。 ------------------------- Re:负载均衡SLB常见咨询问题（持续连载至2015年1月第3周） 2015年1月第3周 1.发现很多100.97.0.0/16 的ip段扫描，给我服务器带来很大压力，怎么办？ 100.97.0.0/16 是我们slb的健康检查服务ip段，如果给服务器带来较大压力，请调整健康检查的设置；健康检查的话 1）调低检查频率 2）设置检查静态文件，而不是默认首页或者动态文件 3）设置一个不记录日志的virtualhost，专门用于健康检查。 2）SLB里的带宽 和后面对应服务器的带宽有什么关联关系？比如SLB我设置了带宽为10M， 但是我后 面2台服务器购买的带宽都只有2M， 这种情况带宽以哪个为准？ 如果您设置的是常规7层slb负载均衡，那么网站访问所使用的带宽，都将通过slb而不需要消耗云服 务器的带宽，但是云服务器本身的系统更新，以及您更新网站等等也是需要带宽的，因此您保留2M 即可。 3)采用流量计费方式的话带宽是否没有限制? SLB按流量计费最大的带宽是1G。 4)请问我如何获得一个外网SLB期所对应的内网IP呢？比如现在我有一个外网SLB下挂了一个ECS， 而ECS的iptables里我想做一些配置，针对来自于这个SLB的请求做一个判断，我需要知道这个外网 SLB的内网IP。 目前SLB与后端通过如下地址段进行交互： 10.158.0.0/16 10.159.0.0/16 100.97.0.0/16 您可以针对上述地址段做相关配置。 5)如何确保SLB后端的多台ECS之间的数据同步呢? 目前，有很多类似的工具可以实现服务器之间的数据同步，比如：rsync。具体使用及选择，还请通 过其他途径获得更多的介绍资料及指导信息。您也可以将您的ECS配置成无状态的应用服务器，而数 据和文件统一存放在RDS和OSS服务上。 ------------------------- 2015年1月第4周1.为什么我的SLB实例突然消失了？请检查您的SLB服务是否设置了自动释放时间导致。2.我想关掉负载均衡，怎么操作？您直接登录到阿里云管理控制台——slb负载均衡——实例中查询创建的slb服务，后方有“释放”的按钮，您直接释放即可。3. 我现在有两个阿里账号里面都有ECS，我能不能在一个slb里面配置不同阿里云账户下的ECS？目前只能将同一账户下的服务器添加到SLB中，无法跨账户添加。4.ECS做负载均衡需要用户做额外的配置吗？可以参考http://help.aliyun.com/knowledge_detail.htm?knowledgeId=5973987。5. 云服务器上做数据库负载均衡如何实现，需要购买什么产品 ？文件服务器能否做负载均衡，比如10台文件服务器，包括读写这种的  ？1）数据库集群,用slb理论上是可以做的,但是如果您需要集群级别的数据库,建议使用我们的RDS。2）文件服务器也可以负载均衡,使用slb在均衡,保持会话,但是有一个问题是后端文件同步的,需要您自行同步,如 rsync。6.看SLB的说明是支持ddos的防护的，请问下，SLB的防护的峰值是多少，超过峰值黑洞时间是多少？这个与slb所在地区有关，和ecs的防御阀值是一样的，黑洞时间也是2.5小时。7. slb第七层是基于haproxy还是nginx还是tengine实现的？使用tengine实现的。8.7层和4层 SLB的超时时间是多少？7层超时时间是60s，4层超时时间是900s。9.负载均衡健康检查请求数量太多，怎么回事？因为slb前端机器是一组机器，所以健康检查请求较多，请您不要担心，集群内的每台服务都会对您的健康按照您设定的频率去做健康检查：您可以按照上述方法去优化您的健康检查项，看似请求量很大，但是对您资源消耗很少的，有2个建议给您：1）扩大健康检查的频率2）将检查页面配置为静态页面。这样请求消耗的资源会节省。10. SLB配置中的最小连接数是基于什么样判断？SLB会自动判断 当前ECS 的established 来判断是否转发。 ------------------------- 2015年2月第1周1)我想了解下SLB按流量计费是不是每小时需要扣0.02元?按量付费，国内节点配置费用是按照0.02/小时。流量单独计费。按带宽计费:采取按小时计费，以日结算（运行未满一日，按照当日实际使用小时数*当日开通的最高带宽的天价格/24）。如果您使用SLB实例的时间不足一小时，按一小时收费。2）请问健康检查发的什么请求？ head 还是 get？head请求。3）SLB最大连接数如何来设置？目前暂不支持设置最大连接数限制。4）SLB 后端有两个服务器HA1和HA2，为什么我将HA1的权重设置成0，SLB的健康检查就有告警呢？slb四层的话，只要权重设置为0，那么健康检查就是显示异常。 ------------------------- 2015年2月第3周1)负载均衡SLB的实例防攻击防御是多少？我们有云盾的防御黑洞策略，比如以杭州节点的slb，其最高防御的流量阈值为5G，当最大流量超过5Ｇ，您的slb vip则会被加入到黑洞中，触发黑洞会使ecs或者slb正常使用中断2.5小时，这个您可以通过云盾管理控制台查看到这个说明。2） 我其他机房的服务器能添加到你们的负载均衡SLB中吗？不可以的，slb使用的是内网和后端的ECS互联，无法直接添加非阿里云主机的服务器，且slb后端的ecs需要使用同一节点的主机。3）负载均衡服务支持的最大负载均衡实例数目多少？总体峰值可支持每秒新建链接数大约多少？SLB对于后端服务器的数目是没有限制的。对于总体峰值每秒新建连接数是没有限制的。但是因为SLB前端是云盾服务，所以最大值取决于云盾中您配置的请求数。您可以查看云盾看到具体的值。4）SLB按量计费为什么需要设置带宽峰值？如果不设置带宽峰值，遇到攻击等情况，可能流量打的非常高的，带宽流量峰值您可以在slb控制台设置。5）在SLB控制面板看到的流入流量，要比后端服务器的eth0的income流量小很多， 请问slb的流入流量是否应该等于后端服务器的内网网卡入流量吗？不等于的，后端的eth0包括了slb的流量，还有其他的流量，包括ecs直接的内网通信等。slb只做转发，不处理请求的，slb通过内网转发到ecs。6）SLB中的月账单 是指我们拥有所有的 SLB 实例的计费呢，还是单独的某个 SLB 的计费？月账单是指您不同类型产品，截止当前日期内月内消费计费额度的，是所有SLB产品的。您也可以通过账单明细进行查询具体信息的。 ------------------------- 2014年2月第4周1）10.159.63.55,这个内网ip，总是恶意访问我们网站？SLB系统除了会通过系统服务器的内网IP将来自外部的访问请求转到后端ECS上之外，还会对ECS进行健康检查（前提是您已经开启了这一功能）和对您的SLB服务进行可用性监控，这些访问的来源都是由SLB系统发起的，具体包含的IP地址段是：杭州、青岛、北京、深圳节点SLB系统IP地址段：10.159.0.0/16，10.158.0.0/16和100.97.0.0/16，为了确保您对外服务的可用性，请确保对上述地址的访问配置放行规则。2）slb计费方式变更需要多久，业务会受到影响么？变更计费方式与变更配置说明1、支持用户在按使用流量和按公网带宽2种计费方式间切换；2、支持按固定带宽方式计费的用户灵活变更带宽配置；3、在一个自然日内，限制用户变更计费方式的次数为1次，变更计费方式将在第二日零点后生效；比如：用户在今天5月5日的10:00提交了变更计费方式，那么该变配申请将在明天5月6日00:00后生效。4、按固定带宽方式计费变更带宽配置即时生效，带宽计费取自然日内用户开通的最高带宽。5、对客户业务不会造成影响；3）负载均衡能将我的外部非阿里云服务器和ECS服务器放到一块？目前负载均衡SLB仅支持阿里云ECS，无法支持外部非阿里云服务器。4）slb是否有连接数限制，需要大量终端一直与平台保持长连接，阿里云能提多少长连接？SLB没有并发连接数限制的，slb是转发请求不做处理，实际连接数还要跟您后端的处理能力有关。 ------------------------- 2015年3月第1周1）调整权重会对SLB已经有的正常连接有影响吗？目前调整权重会对调整权重的这台主机已有的连接产生影响，会有连接卡主，卡住时间由健康检查配置的时间决定。2)slb是否支持UDP协议？目前SLB暂不支持UDP协议。3）现在TCP四层负载均衡的出口带宽受ECS机器的出口带宽限制吗？slb和ECS之间走的是内网流量，带宽是不受限制的。4）如果没有外网ip, 是否可以用slb的4层转发 ?没有带宽4层SLB也是可以使用的。 ------------------------- Re:负载均衡SLB常见咨询问题（持续连载至2015年3月第1周） 2015年3月第2周 1)SLB变更计费方式并支付成功后无法添加配置? SLB在一个自然日内，限制用户变更计费方式的次数为1次，变更计费方式将在第二日零点后生效查看您今天变更过一 次计费方式，开始时间：2015-03-09 00:00:00。原按使用流量计费，在2015-03-09 00:00:00后变更为按固定带宽计 费，带宽峰值: 2Mbps。同时在您新的计费方式生效之前，您是无法对该SLB进行修改配置的。 2）我的账户怎么欠费￥7.88，这是怎么回事？ 查看您有使用负载均衡slb业务，在slb产品的账单欠费，请您登陆用户中心-消费记录-账单明细中查看 记录。 3）如何屏蔽健康检查探测的日志记录？ 关闭或者屏蔽对test.php访问日志的方式： 在站点配置文件中添加内容： location ~ /test.php { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 注： 1、对test.php的location必须要放置在对php|php5处理前，否则会因为先被进行全局匹配导致无法生效。 2、还可以用另一种方案实现： a、在后端服务器中单独为用于健康检查的页面建立一个站点； b、关闭这个站点的日志记录： location ~ .*\.(php|php5)?$ { access_log off; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } 3、如果检查页面是其他格式，比如test.html，可以采用如下方式进行屏蔽： location ~ /test.html { access_log off; } 4.我想问下SLB的固定带宽，10M是不是上行和下行最大都能达到10M？ 固定带宽指的是下行带宽最大达到10M，上行带宽没有限制。上行带宽指的是SLB的入流量（上行），就是进入SLB的 流量。带宽指的是SLB的出流量（下行），就是SLB对外发生给客户端的流量。 5.一般配置SLB的时候有个权重0到100，是如何选择数值的？ 权重需要您根据后端机器的配置进行选择比如AB两台机器性能一致就分别设置50，这样请求就会在这两台机器上轮询 ，不同权重决定请求分发的分配。 ------------------------- 2015年3月第3周1）公网的SLB和ECS之间的流量是否收费？不收费。2） 想做SLB+两台ECS，附件OSS，程序Discuz。但是不知道如何实现?slb要求后端的两台ecs数据是一致的,为了保持数据的一致性，建议共享存数和数据，静态文件放置到oss里，数据库文件走自己搭建的主从或者，连接同一台rds。3）按流量计算是否需要设置峰值？按流量计费不需要设置峰值的。4）如何建一个子帐号来管理负载均衡SLB?子账户无法管理负载均衡服务。

回 1楼竹梅的帖子 先请教下第三个问题，组织机构的导入如图，如果导入员工的时候，组织结构在现有架构中不存在，会自动创建吗，相应的这条员工信息能正常导入吗 ------------------------- 回 1楼竹梅的帖子 包括已发送的DING能否删除，如果没有后续会提供吗 ------------------------- 回 5楼识器的帖子 您说的多部门的情况，是否是 “浙江分公司-市场部，产品中心-杭州分部”格式 ，还有其中的“-”、“，”是否使用英文符号？还有因为和企业关联，如果企业内部系统有人员或组织机构的变动能否和钉钉中的组织机构及时同步 ------------------------- 回 7楼识器的帖子 想请教一下，因为我现在一直在查阅服务器端和PC端开发，文档上说的集成是将PC端直接作为一个模块嵌入到企业系统中还是可以单独引用js文件，然后从企业系统中直接调用PC端文档中提供的接口？ 如果是第二种， https://bbs.aliyun.com/read/271871.html?spm=0.0.0.0.jdUn7t 这样写有什么问题？     谢谢    

业务代码中有数据库事务锁，其实是卡在事务上了，或者是某个地方不恰当的使用了锁######回复 @malie0 : 打断点应该属于特殊情况，你直接Thread.sleep(5000L)并发测，再看看请求响应的顺序。######回复 @malie0 : debug看下，线程池是不是耗尽了######应该没用到事务锁，response后面的代码可以什么都不写，就一个systemout的打印输出，然后打个断点，后面的请求就会卡住######在reponse返回的代码后面接下来继续处理业务逻辑 什么意思？reponse写出流之后，继续使用线程？那这个线程不会返回给servlet容器的线程池，接下来的请求会被给线程池中其他的线程######回复 @gaomq : 但是只要执行了response的返回就能立刻返回给前台的，跟后台有没有执行完方法没关系，应该不需要用异步servlet######回复 @malie0 : reponse想先返回，需要开异步。一个request和response处理一次请求。######对啊，就是当前线程在返回response响应代码后继续在处理业务逻辑，按照道理后面的请求会用另一个线程去处理，但是卡住了，只有等到这个线程处理完了才会处理下一个请求######http1.1在一个连接上，前一个请求收到响应才会发起下一个请求，是串行的。比如：请求1-->响应1，然后请求2-->响应2。 浏览器对同一个域名能建立的连接是有数量限制的。 猜测你的两个请求走的是同一个连接。######回复 @gaomq : 查到了这个，你看看https://stackoverflow.com/questions/45583861/how-does-http2-solve-head-of-line-blocking-hol-issue#answer-45583977，有问题再交流。######回复 @gaomq :谢谢你的回复，我又想了想，“并且多个请求可以重叠进行”好像不行。假如请求1和2连续发出，服务器端请求1由线程1处理，请求2由线程2处理，线程2处理的快，先写出了响应（响应2的TCP包应该是在响应1的前面的，但我不确定），客户端应该是识别不出这个响应是请求1还是请求2的。你有没有文章佐证你的观点。我说的是串行的，是我从http1.1和http2区别上看到的。######http 1.1则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求######这个有没有办法解决，让他们走不同的连接，前台ajax或者后台的servlet的配置？######应该是你前端的业务是串行执行的吧，后端单线程还是多线程都是可以自己配置的，不同的web层框架，配置的方式不同。######前端是在得到一个响应后才会触发另一个，但是对于后端来说应该两次响应要用不同的线程去处理，现在的情况感觉后端就是用了同一个线程在处理，所以出现了串行的问题######ajax不是可以设置是否异步处理，######ajax应该是异步的。就算是同步也不是导致我的问题的原因，因为ajax已经根据第一次返回的响应发起了第二次请求，后台是第二次请求发起后阻塞了。ajax的异步和同步只是前端要不要等待响应结果才做其他事情还是在请求没返回响应的时候还能执行其他代码######java servlet是多线程的，http1的ajax是阻塞的，也就是只有等到结果返回才能进行下次请求，http2的ajax才是真正的异步，http1、http2这个是刚好前几天在这里看到一篇博客。######但是我的问题是前端已经接收到第一次请求的响应才发起第二个请求，后端在第二个请求的时候阻塞了，我觉得跟前端应该已经没关系了######感觉像是AJAX没有开启异步处理吧。######请问这个问题解决了吗？请教下

主从mysql 读写分离。。在搞个cache层。。。鄙人一点见解这方便没什么经验###### 必须被肯定的是你的想法，数据推送到APP上从内存中查是非常好的解决方案。至于如何同步更新有很多种方法，有主动侦听的也有被动推送的，相信你一定能找到符合自己的办法。 目前想到的是先将数据库中所有的配置读到内存，在更改mysql中的配置时，系统再读一次修改项，但是对于状态，因为要查询状态，必须保证状态尽量是最新的。 这句话隐藏着玄机，“必须”保证状态“尽量”是最新的，如果你能接受“尽量”，那么其实就意味着你的业务是能允许一定的时差的。 ######那些因素都还没来得及考虑。我理解你的建议是，让server功能尽量单一，保证可靠性，配置管理、查询等从server分离。good idea###### @_binary_ 恩，maybe我理解错你的意思了：我理解你的方案是单独拉一台机器来做配置管理(configserver)。web(client) -> server -> configserver，如果我理解错你的方案了，请华丽丽的忽略我之前的说法，哈哈。###### @_binary_ 偶的观点是，如果数据不大的话，或者前置机不是很需要吃内存的话，可以考虑直接将数据同步到前置机的内存中。避免到单点server上查询（哪怕server是在内存中也是会有风险的）###### @_binary_ 啊哈，请问有考虑单点故障么？有考虑日常停机升级维护么？有考虑网络波动么？既然给自己定位一个高并发的系统，这些因素就必须都考虑上，否则会导致业务全面崩溃。不开玩笑的～这绝对不是简单的做个主备就搞定的事情，还考虑到服务质量控制（没错，你已经是一个C/S模型了）######这是server端程序，client只负责发数据。server负责比较、状态更新、查询等功能，一台就够了######try  Mysql Memory Engine for your conf table

134题 其实就是水平扩容了，Zookeeper在这方面不太好。两种方式：全部重启：关闭所有Zookeeper服务，修改配置之后启动。不影响之前客户端的会话。逐个重启：这是比较常用的方式。 133题 集群最低3（2N+1）台，保证奇数，主要是为了选举算法。一个由 3 台机器构成的 ZooKeeper 集群，能够在挂掉 1 台机器后依然正常工作，而对于一个由 5 台服务器构成的 ZooKeeper 集群，能够对 2 台机器挂掉的情况进行容灾。注意，如果是一个由6台服务器构成的 ZooKeeper 集群，同样只能够挂掉 2 台机器，因为如果挂掉 3 台，剩下的机器就无法实现过半了。 132题 基于“过半”设计原则，ZooKeeper 在运行期间，集群中至少有过半的机器保存了最新的数据。因此，只要集群中超过半数的机器还能够正常工作，整个集群就能够对外提供服务。 131题 不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，这太消耗性能了。一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。 130题 数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master 选举，分布式锁，分布式队列 129题 客户端 SendThread 线程接收事件通知， 交由 EventThread 线程回调 Watcher。客户端的 Watcher 机制同样是一次性的， 一旦被触发后， 该 Watcher 就失效了。 128题 1、服务端接收 Watcher 并存储； 2、Watcher 触发； 2.1 封装 WatchedEvent； 2.2 查询 Watcher； 2.3 没找到；说明没有客户端在该数据节点上注册过 Watcher； 2.4 找到；提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher； 3、调用 process 方法来触发 Watcher。 127题 1.调用 getData()/getChildren()/exist()三个 API，传入 Watcher 对象 2.标记请求 request，封装 Watcher 到 WatchRegistration 3.封装成 Packet 对象，发服务端发送 request 4.收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理 5.请求返回，完成注册。 126题 Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。工作机制：（1）客户端注册 watcher（2）服务端处理 watcher（3）客户端回调 watcher 125题 服务器具有四种状态，分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。 LOOKING：寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。 FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。 LEADING：领导者状态。表明当前服务器角色是 Leader。 OBSERVING：观察者状态。表明当前服务器角色是 Observer。 124题 Zookeeper 有三种部署模式：单机部署：一台集群上运行；集群部署：多台集群运行；伪集群部署：一台集群启动多个 Zookeeper 实例运行。 123题 Paxos算法是分布式选举算法，Zookeeper使用的 ZAB协议（Zookeeper原子广播），二者有相同的地方，比如都有一个Leader，用来协调N个Follower的运行；Leader要等待超半数的Follower做出正确反馈之后才进行提案；二者都有一个值来代表Leader的周期。不同的地方在于：ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。Paxos算法、ZAB协议要想讲清楚可不是一时半会的事儿，自1990年莱斯利·兰伯特提出Paxos算法以来，因为晦涩难懂并没有受到重视。后续几年，兰伯特通过好几篇论文对其进行更进一步地解释，也直到06年谷歌发表了三篇论文，选择Paxos作为chubby cell的一致性算法，Paxos才真正流行起来。对于普通开发者来说，尤其是学习使用Zookeeper的开发者明确一点就好：分布式Zookeeper选举Leader服务器的算法与Paxos有很深的关系。 122题 ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议(paxos算法的一种实现)。ZAB协议包括两种基本的模式：崩溃恢复和消息广播。当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时，所有进程（服务器）进入崩溃恢复模式，首先选举产生新的Leader服务器，然后集群中Follower服务器开始与新的Leader服务器进行数据同步，当集群中超过半数机器与该Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。 121题 Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；如果是一个Leader宕机，Zookeeper会选举出新的Leader。ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。所以，3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)，2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)。 120题 选完Leader以后，zk就进入状态同步过程。1、Leader等待server连接；2、Follower连接leader，将最大的zxid发送给leader；3、Leader根据follower的zxid确定同步点；4、完成同步后通知follower 已经成为uptodate状态；5、Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。 119题 在zookeeper集群中也是一样，每个节点都会投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是leader节点了。zookeeper中有三种选举算法，分别是LeaderElection,FastLeaderElection,AuthLeaderElection， FastLeaderElection此算法和LeaderElection不同的是它不会像后者那样在每轮投票中要搜集到所有结果后才统计投票结果，而是不断的统计结果，一旦没有新的影响leader结果的notification出现就返回投票结果。这样的效率更高。 118题 zk的负载均衡是可以调控，nginx只是能调权重，其他需要可控的都需要自己写插件；但是nginx的吞吐量比zk大很多，应该说按业务选择用哪种方式。 117题 Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 116题 有临时节点和永久节点，分再细一点有临时有序/无序节点，有永久有序/无序节点。当创建临时节点的程序结束后，临时节点会自动消失，临时节点上的数据也会一起消失。 115题 在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，这就是主节点存在的意义。 114题 ZooKeeper 实现分布式事务，类似于两阶段提交，总共分为以下 4 步：客户端先给 ZooKeeper 节点发送写请求；ZooKeeper 节点将写请求转发给 Leader 节点，Leader 广播给集群要求投票，等待确认；Leader 收到确认，统计投票，票数过半则提交事务；事务提交成功后，ZooKeeper 节点告知客户端。 113题 ZooKeeper 实现分布式锁的步骤如下：客户端连接 ZooKeeper，并在 /lock 下创建临时的且有序的子节点，第一个客户端对应的子节点为 /lock/lock-10000000001，第二个为 /lock/lock-10000000002，以此类推。客户端获取 /lock 下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁，否则监听刚好在自己之前一位的子节点删除消息，获得子节点变更通知后重复此步骤直至获得锁；执行业务代码；完成业务流程后，删除对应的子节点释放锁。 112题 ZooKeeper 特性如下：顺序一致性（Sequential Consistency）：来自相同客户端提交的事务，ZooKeeper 将严格按照其提交顺序依次执行；原子性（Atomicity）：于 ZooKeeper 集群中提交事务，事务将“全部完成”或“全部未完成”，不存在“部分完成”；单一系统镜像（Single System Image）：客户端连接到 ZooKeeper 集群的任意节点，其获得的数据视图都是相同的；可靠性（Reliability）：事务一旦完成，其产生的状态变化将永久保留，直到其他事务进行覆盖；实时性（Timeliness）：事务一旦完成，客户端将于限定的时间段内，获得最新的数据。 111题 ZooKeeper 通常有三种搭建模式：单机模式：zoo.cfg 中只配置一个 server.id 就是单机模式了，此模式一般用在测试环境，如果当前主机宕机，那么所有依赖于当前 ZooKeeper 服务工作的其他服务器都不能进行正常工作；伪分布式模式：在一台机器启动不同端口的 ZooKeeper，配置到 zoo.cfg 中，和单机模式相同，此模式一般用在测试环境；分布式模式：多台机器各自配置 zoo.cfg 文件，将各自互相加入服务器列表，上面搭建的集群就是这种完全分布式。 110题 ZooKeeper 主要提供以下功能：分布式服务注册与订阅：在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，比较典型的服务注册与订阅，如 Dubbo。分布式配置中心：发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到 ZooKeeper 节点上，供订阅者获取数据，实现配置信息的集中式管理和动态更新。命名服务：在分布式系统中，通过命名服务客户端应用能够根据指定名字来获取资源、服务地址和提供者等信息。分布式锁：这个主要得益于 ZooKeeper 为我们保证了数据的强一致性。 109题 Dubbo是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。 108题 Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。 107题 Dubbo超时时间设置有两种方式： 服务提供者端设置超时时间，在Dubbo的用户文档中，推荐如果能在服务端多配置就尽量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。 服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会定制，会产生警告。 106题 Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀； RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题； LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求； ConstantHash LoadBalance: 一致性Hash策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动； 缺省时为Random随机调用。 105题 Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心。 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。 Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。 Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer。 104题 Provider：暴露服务的服务提供方。 Consumer：调用远程服务的服务消费方。 Registry：服务注册与发现的注册中心。 Monitor：统计服务的调用次调和调用时间的监控中心。 Container：服务运行容器。 103题 主要就是如下3个核心功能： Remoting：网络通信框架，提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。 Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。 Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 102题 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 101题 垂直分表定义：将一个表按照字段分成多表，每个表存储其中一部分字段。水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。 100题 垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。 99题 QPS：每秒查询数。TPS：每秒处理事务数。Uptime：服务器已经运行的时间，单位秒。Questions：已经发送给数据库查询数。Com_select：查询次数，实际操作数据库的。Com_insert：插入次数。Com_delete：删除次数。Com_update：更新次数。Com_commit：事务次数。Com_rollback：回滚次数。 98题 如果需要跨主机进行JOIN，跨应用进行JOIN，或者数据库不能获得较好的执行计划，都可以自己通过程序来实现JOIN。 例如：SELECT a.,b. FROM a,b WHERE a.col1=b.col1 AND a.col2> 10 ORDER BY a.col2; 可以利用程序实现，先SELECT * FROM a WHERE a.col2>10 ORDER BY a.col2;–(1) 利用(1)的结果集，做循环，SELECT * FROM b WHERE b.col1=a.col1; 这样可以避免排序，可以在程序里控制执行的速度，有效降低数据库压力，也可以实现跨主机的JOIN。 97题 搭建复制的必备条件：复制的机器之间网络通畅，Master打开了binlog。 搭建复制步骤：建立用户并设置权限，修改配置文件，查看master状态，配置slave，启动从服务，查看slave状态，主从测试。 96题 Heartbeat方案：利用Heartbeat管理VIP，利用crm管理MySQL，MySQL进行双M复制。（Linux系统下没有分库的标准方案）。 LVS+Keepalived方案：利用Keepalived管理LVS和VIP，LVS分发请求到MySQL，MySQL进行双M复制。（Linux系统下无分库无事务的方案）。 Cobar方案：利用Cobar进行HA和分库，应用程序请求Cobar，Cobar转发请求道数据库。（有分库的标准方案，Unix下唯一方案）。 95题 聚集（clustered）索引，也叫聚簇索引，数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。但是，覆盖索引可以模拟多个聚集索引。存储引擎负责实现索引，因此不是所有的存储索引都支持聚集索引。当前，SolidDB和InnoDB是唯一支持聚集索引的存储引擎。 优点：可以把相关数据保存在一起。数据访问快。 缺点：聚集能最大限度地提升I/O密集负载的性能。聚集能最大限度地提升I/O密集负载的性能。建立在聚集索引上的表在插入新行，或者在行的主键被更新，该行必须被移动的时候会进行分页。聚集表可会比全表扫描慢，尤其在表存储得比较稀疏或因为分页而没有顺序存储的时候。第二（非聚集）索引可能会比预想的大，因为它们的叶子节点包含了被引用行的主键列。 94题 以下原因是导致mysql 表毁坏的常见原因： 服务器突然断电导致数据文件损坏； 强制关机，没有先关闭mysql 服务； mysqld 进程在写表时被杀掉； 使用myisamchk 的同时，mysqld 也在操作表； 磁盘故障；服务器死机；mysql 本身的bug 。 93题 1.定位慢查询 首先先打开慢查询日志设置慢查询时间； 2.分析慢查询（使用explain工具分析sql语句）； 3.优化慢查询 。

回 1楼(anywn) 的帖子 自建FTP的方法只适合小数据量，数据文件的个数小的前提下的。但是如果是数据文件个数大的前提下，自建FTP的方法，很不实际。楼主可以尝试使用过FTP下载1000个100KB到200KB的文件。看一下所需的时间，再尝试把1000个文件打包，在下载到本地。两者时间对比是完全没得比的！ ------------------------- 回 3楼(vpsmm) 的帖子 是可以同步！但是需要的时间太久！同时我也听到了身边一些使用OSS的朋友的疑问，说使用阿里云论坛里面的“JAVA客户端”进行大数据量的数据同步数据是否需要计算进流量里面的！还有put、get等的计算…… ------------------------- 回 6楼(liming837) 的帖子 嗯，支持！楼上的看法 ------------------------- 回 9楼(bohj008) 的帖子 你永远把数据放阿里云OSS上吗？你本地不需要备份的吗？ ------------------------- 回 8楼(tftaxis) 的帖子 嗯，是啊！所以建议阿里云OSS推出打包备份的功能！同时流量费没必要计入OSS使用计费里面! 至于如果涉及到防止滥用的打包备份的功能，则可以选择需要备份的则需要先发工单申请什么的！或者其他的方式！ ------------------------- 再来顶一下！ ------------------------- 回 14楼(ap6214f2r) 的帖子 嗯，楼主高见！虽然麻烦点！但是这个是最好的方法了！

转自：阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问： 谁选型？是负责采购的同学、 DBA 还是业务研发？ 如果选型的是采购的同学，他们更注重成本，包括存储方式、网络需求等。 如果选型的是 DBA 同学，他们关心的： ① 运维成本 首先是运维成本，包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等； ② 稳定性 其次，DBA会关注稳定性，包括是否支持数据多副本、服务高可用、多写多活等； ③ 性能 第三是性能，包括延迟、QPS 以及是否支持更高级的分级存储功能等； ④ 拓展性 第四是扩展性，如果业务的需求不确定，是否容易横向扩展和纵向扩容； ⑤ 安全 最后是安全，需要符合审计要求，不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外，后台应用研发的同学同样会关注稳定性、性能、扩展性等问题，同时也非常关注数据库接口是否便于开发，是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型： MySQL，互联网业务必备系统； TiDB，爱奇艺的 TiDB 实践会有另外的具体介绍； Redis，KV 数据库，互联网公司标配； Couchbase，这个在爱奇艺用得比较多，但国内互联网公司用得比较少，接下来的部分会详细说明； 其他，比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等； 大数据分析相关系统，比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的，这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么，我们先对这些数据库按照接口（SQL、NoSQL）和面向的业务场景（OLTP、OLAP）这两位维度进行一个简单非严谨的分类。 下图中，左上角是面向 OLTP、支持 SQL 的这样一类系统，例如 MySQL，一般支持事务不同的隔离级别， QPS 要求比较高，延时比较低，主要用于交易信息和关键数据的存储，比如订单、VIP 信息等。 左下角是 NoSQL 数据库，是一类针对特殊场景做优化的系统，schema 一般比较简单，吞吐量较高、延迟较低，一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统，包括 Clickhouse、Impala等，一般支持SQL、不支持事务，扩展性比较好，可以通过加机器增加数据的存储量，响应延迟较长。 还有一类数据库是比较中立的，在数据量比较小的时候性能比较好，在数据量较大或复杂查询的时候性能也不差，一般通过不同的存储引擎和查询引擎来满足不同的业务需求，我们把它叫做 HTAP，TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库，那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步，支持每周全备+每日增量备份。我们做了一些基本功能的增强，首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况，我们有一个全量库是 300G 数据，增量库每天 70G 数据，总数据量 700G 左右。我们当时只需要恢复一个表的数据，但该工具不支持单表恢复，且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因，发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作，所以我们做了一些优化。例如删减过程中的一些写盘操作，减少落盘并将数据处理并行化，优化后整库恢复耗时减少到 100 分钟，而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统，gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时，所以我们在使用工具的时候也增加了延时上的考虑，实时探测Master-Slave 库之间延时的情况，如果延时较大会暂停工具的使用，恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善，所以我们参照了 MHA 并进行了改动，采用 master + agent 的方式。Agent 在每一个物理机上部署，可以监控这个物理机上的所有实例的状态，周期性地向 master 发送心跳，Master 会实时监测各个Agent的状态。 如果 MySQL故障，会启动 Binlog 补偿机制，并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况，MHA 的 master 我们也做了高可用设计，众多 master 会通过 raft 组成一个 raft group，类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式：同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力，以提供更大容量的数据存储。扩展方式有 SDK，例如开源的 ShardingSphere，在爱奇艺的使用也比较广泛。另外就是 Proxy，开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单，扩容难度大，依赖较多且运维复杂，所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作，后端打到 Kafka，下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略，包括主动探索是否有 SQL 注入及是否存在拖库情况等，并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响，对此我们进行了一些测试，发现使用 General Log 对性能损耗较大，有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项，再把监控项放到 buffer 里边，用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程，从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent，从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测，在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据，性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间，运行比较稳定，上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据，即只需要读写最近一段时间存入的数据，过段时间这些数据就不需要了，需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式，例如 TiDB 或其他 TokuDB，两者之间可以进行数据自动搬迁和自动归档，同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来，业务的开发同学只需要将数据存入 MySQL 里，读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用，之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式，由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置，在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景，虽然 Redis 是一个缓存，但我们发现不少的业务同学会把它当做一个 KVDB 来使用，在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能，启动一个进程伪装成 Redis 的 Slave 实时获取数据，再放到后端的 KV 存储里，例如 ScyllaDB，如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时，会由 Sentinel 重新选出一个新的节点成为 Master，再把该节点上的数据同步到所有 Slave 上，此过程中数据会放在 Master 节点的 Buffer 里，如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去，重建过程就会失败。 基于这种情况，我们对 Redis 告警做了自动化优化，如有大量 master - slave 重建失败，我们会动态调整一些参数，例如把 Buffer 临时调大等， 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群，如果某个分片发生了故障或者 failover，Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题，整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis，如果某个分片发生故障，就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名，多个从库绑定读域名。但如果我们进行 Master failover，会将读写域名从某旧 Master 解绑，再绑定到新 Master 节点上。 DNS 本身有一个超时时间，所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话，有可能还会连到原来的机器上，造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短，但对 DNS 服务又会造成很大的压力，所以我们在 SDK 上提供 Redis 的名字服务 RNS，RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况，如果集群 failover，Sentinel 会接到通知，客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名，通过 IP 地址来访问整个集群，屏蔽了 DNS 的超时，缩短了故障的恢复时间。 SDK 上还做了一些功能，例如 Load Balance 以及故障检测，比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦，如果客户端已经进行了一定量的分片，之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster，因为功能受限在爱奇艺应用的不是很多，例如不支持显示跨 DC 部署和访问，读写只在主库上等。 我们某些业务场景下会使用 Redis 集群，例如数据库访问只发生在本 DC，我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover，如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy，读写都通过它来进行。写入数据时 Proxy 会做一个旁路，把新增的数据写在 Kafka 里，后台启用同步程序再把 Kafka 里的数据同步到其他集群，但存在一些限制，比如我们没有做冲突检测，所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式，但存在一些问题。所以数据量较大的时候（经验是 160G），就不推荐 Redis 了，而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少，一开始我们是把他当做一个 Memcached 来使用的，即纯粹的缓存系统。 但其实它性能还是比较强大的，是一个分布式高性能的 KV 系统，支持多种存储引擎 (bucket)。第一种是 Memcached bucket，使用方式和 Memcached 一样为 KV 存储，不支持数据持久化也没有数据副本，如果节点故障会丢失数据； 第二种是 Couchbase bucket，支持数据持久化，使用 Json 写入，有副本，我们一般会在线上配置两个副本，如果新加节点会对数据进行 rebalance，爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图，数据写入时在客户端上会先进行一次哈希运算，运算完后会定位 Key 在哪一个 vBucket （相当于数据库里的某个分片）。之后客户端会根据 Cluster Map 发送信息至对应的服务端，客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系，在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新，因此客户端对于服务端的 failover 操作不需要做特殊处理，但可能在 rebalance 过程中会有短暂的超时，导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早，2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发，最大功能是进行集群间的复制，提供多种复制方式：单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本，正在调研的 6.0，中间也遇到了很多坑，例如 NTP 时间配置出错会导致崩溃，如果每个集群对外 XDCR 并发过高导致不稳定，同步方向变更会导致数据丢失等等，我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群，集群间的数据同步通过 XDCR，我们一般配置为双向同步。对于业务来说，如果 Cluster 1 写入， Cluster 2 不写入，正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障，我们提供了一个 Java SDK，可以在配置中心把写入更改到 Cluster 2，把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高，并且数据的存储可以超过内存。但是，如果数据量超过内存 75% 这个阈值，性能就会下降地特别快。在爱奇艺，我们会把数据量控制在可用内存的范围之内，当做内存数据库使用。但是它的成本非常高，所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB，主要使用了其分布式数据库的管理功能，增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍，又完全兼容 Cassandra 接口，设计基本一致，可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架，例如 C++ 异步框架 seastar，主要原理是在j每台物理机的核上会 attach 一个应用线程，每个核上有自己独立的内存、网络、IO 资源，核与核之间没有数据共享但可以通信，其最大的好处是内存访问无锁，没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时，会按照哈希算法来判断请求的 Key 是否是该线程需要处理的，如果是则本线程处理，否则会转发到对应线程上去。 除此之外，它还支持多副本、多数据中心、多写多活，功能比较强大。 在爱奇艺，我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里，Value 放在盘上的文件里，我们在读和写文件时，只需要在内存索引里定位，再进行一次盘的 IO 开销就可以把数据读出来，相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中，如果索引长度较长会限制单机可存储的数据量，于是我们通过开发定长的内存分布器，对于比较长的 Key 做摘要缩短长度至 20 字节，采用红黑树索引，限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint，客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大，截至目前已经替换了 30% 的 Couchbase，有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多，如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理，如果脚本出问题就找 DBA，导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案，于是在内部构建了一个私有云，通过 Web 的方式展示数据库运行状态，让业务的同学可以自己去申请集群，一些简单的操作也可以通过自服务平台实现，解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障，敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化，通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具，比如有业务同学说 MySQL master-slave 延时了，DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具，出问题时业务的同学可以自己通过网页上的一键诊断工具去排查，自助进行处理。 除此之外我们还会定期做预警检查，对业务集群里潜在的问题进行预警报告；开发智能客服，回答问题；通过监控的数据对实例打标签，进行削峰填谷地智能调度，提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起，通过经验得出来的一些结论。 对于关系型数据库的选型来说，可以从数据量和扩展性两个维度考虑，再根据数据库有没有冷备、要不要使用 Toku 存储引擎，要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave，什么情况下使用客户端分片、集群、Couchbase、HiKV 等，我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求，判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求，但这些都是真实需求吗？是否可以通过其他方式把这个需求消耗掉，例如在数据量大的情况下可以先做数据编码或者压缩，数据量可能就降下来了。 不要把所有需求都推到数据库层面，它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么？是因为热门吗？还是因为技术上比较先进？但是不是能真正地解决你的问题？如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃，当你放弃一个系统时真的是因为不好用吗？还是没有用好？放弃一个东西很难，但在放弃时最好有一个充分的理由，包括实测的结果。 ④ 自研 第四是自研，在需要自己开发数据库时可以参考和使用一些成熟的产品，但不要盲目自研。 ⑤ 开源 最后是开源，要有拥抱开源的态度。

回1楼服务器之家的帖子 你没理解我的问题。 不考虑什么共享的问题，排开这些干扰因素， 仅仅从一台8核8G与两台4核4G的机器，哪个跑起来性能更优？还是两者的性能一样？ 我觉得后者的性能更优 ------------------------- 回4楼南极的风的帖子 如果是分布式的，为什么两台要优？我很想听听你的理由。 如果你的应用需要的线程比较多，为什么8核要优，8核分成两个4核，有什么不同吗？ ------------------------- 回6楼南极的风的帖子 分布式的话，多台的扩展性和安全性当然比一台好。 我只是仅仅想从性能方面考虑， 是不是多台性能，比一台性能要高那么点点呢 ------------------------- 回8楼南极的风的帖子 恩。你说的有道理。 但如果应用结合SLB，偏向分布式， 那2台4核和一台8核相比较呢？ ------------------------- Re一台8核8G与两台4核4G的云主机性能对比 单从性能上来将，我觉得两台肯定优于一台。比如IO ------------------------- 回15楼南极的风的帖子 在分布式应用中，多台的IO肯定是多于一台的。 利用虚拟机的磁盘来做IO密集型应用，为什么不适合呢？ 我打个比方，假如我有个项目，上传文件的应用，都是集中在一台云主机上，用ftp。这不用怀疑，这台云主机肯定出现IO瓶颈。 在不考虑用OSS的情况下，我想解决IO问题，必须借助分布式部署。 假如我现在的站点是用slb部署的两台web应用，如果我将ftp上传功能，从一台云主机中抽取出来，用http上传，部署到两台web应用的云主机中。这样，两台云主机的IO肯定会比一台强。你说呢？ ------------------------- 回17楼南极的风的帖子 我都不理解你是怎么想的。 总共三台云主机，两台web，还有一台云主机专门用来做ftp，slb用来做负载。请求到达任意一台web，我直接内网连接那台ftp，将数据存储到ftp中，有何不可？或者直接用外网IP，客户端直接将文件上传到ftp，不经过web服务器中转，也可以。但这里ftp的这台云主机，在后面必然存在IO瓶颈。那就换成刚才我的那种方案。 总共三台云主机，现在我把这台ftp去除，将ftp也变成web，我用三台web，取消ftp上传，我改为http上传。http请求来了，我将文件存储在任意一台web中。三台云主机的文件同步，用nfs就行了。这种方案，不用想，当然要比第一种方案的IO要好。这也是我之前说的那个问题，两台的IO肯定比一台好，也就是这个原因。 ------------------------- 回17楼南极的风的帖子 利用多台虚拟机提高IO的策略，这是个分布式应用的好办法，并不是行不通啊，很多客户也是这么在用。 ------------------------- 回20楼南极的风的帖子 用nfs只是应付小规模，到后面，就不会用nfs，直接结合oss来了。 我只是借用这个例子，说明一下两台比一台的IO要好这个观点而已 ------------------------- 回22楼南极的风的帖子 我已经强调了，不想再重复说明 “用nfs只是应付小规模，到后面，就不会用nfs，直接结合oss来了。” 意思已经说明了，几台服务器的数据同步，一般用nfs就能满足需求。 大规模的应用，根本不会采用服务器之间还数据同步，这样扩展性，及数据同步等等都会给架构带来重大问题，也没人这么做。 一般都是用分布式文件系统解决，在云端，就用云存储oss来解决。这样就不存在还解决什么数据同步的问题，扩展性也不是问题了。

Arraylist和Vector是采用数组方式存储数据，此数组元素数大于实际存储的数据以便增加插入元素，都允许直接序号索引元素，但是插入数据要涉及到数组元素移动等内存操作，所以插入数据慢，查找有下标，所以查询数据快，Vector由于使用了synchronized方法-线程安全，所以性能上比ArrayList要差，LinkedList使用双向链表实现存储，按序号索引数据需要进行向前或向后遍历，但是插入数据时只需要记录本项前后项即可，插入数据较快。线性表，链表，哈希表是常用的数据结构，在进行java开发时，JDK已经为我们提供了一系列相应的类实现基本的数据结构，这些结构均在java.util包中，collection├List│├LinkedList│├ArrayList│└Vector│　└Stack└SetMap├Hashtable├HashMap└WeakHashMapCollection接口Collection是最基本的集合接口，一个Collection代表一组Object，即Collection的元素(elements)，一些Collection允许相同的元素而另一些不行。一些能排序而另一些不行。Java SDK不提供直接继承自Collection的类，Java SDK提供的类都是继承自Collection的“子接口”如List和Set。所有实现Collection接口的类都必须提供两个标准的构造函数：无参数的构造函数用于创建一个空的Collection，有一个Collection参数的构造函数用于创建一个新的Collection，这个新的Collection与传入的Collection有相同的元素。后一个构造函数允许用户复制一个Collection。如何遍历Collection中的每一个元素？不论Collection的实际类型如何，它都支持一个iterator()的方法，该方法返回一个迭代子，使用该迭代子即可逐一访问Collection中每一个元素。典型的用法如下：　　　　Iterator it = collection.iterator(); // 获得一个迭代子　　　　while(it.hasNext()) {　　　　　　Object obj = it.next(); // 得到下一个元素　　　　}　　由Collection接口派生的两个接口是List和Set。List接口　　List是有序的Collection，使用此接口能够精确的控制每个元素插入的位置。用户能够使用索引（元素在List中的位置，类似于数组下标）来访问List中的元素，这类似于Java的数组。和下面要提到的Set不同，List允许有相同的元素。　　除了具有Collection接口必备的iterator()方法外，List还提供一个listIterator()方法，返回一个ListIterator接口，和标准的Iterator接口相比，ListIterator多了一些add()之类的方法，允许添加，删除，设定元素，还能向前或向后遍历。　　实现List接口的常用类有LinkedList，ArrayList，Vector和Stack。ArrayList类　　ArrayList实现了可变大小的数组。它允许所有元素，包括null。ArrayList没有同步。size，isEmpty，get，set方法运行时间为常数。但是add方法开销为分摊的常数，添加n个元素需要O(n)的时间。其他的方法运行时间为线性。　　每个ArrayList实例都有一个容量（Capacity），即用于存储元素的数组的大小。这个容量可随着不断添加新元素而自动增加，但是增长算法并没有定义。当需要插入大量元素时，在插入前可以调用ensureCapacity方法来增加ArrayList的容量以提高插入效率。　　和LinkedList一样，ArrayList也是非同步的（unsynchronized）。Vector类　　Vector非常类似ArrayList，但是Vector是同步的。由Vector创建的Iterator，虽然和ArrayList创建的Iterator是同一接口，但是，因为Vector是同步的，当一个Iterator被创建而且正在被使用，另一个线程改变了Vector的状态（例如，添加或删除了一些元素），这时调用Iterator的方法时将抛出ConcurrentModificationException，因此必须捕获该异常。Stack 类　　Stack继承自Vector，实现一个后进先出的堆栈。Stack提供5个额外的方法使得Vector得以被当作堆栈使用。基本的push和pop方法，还有peek方法得到栈顶的元素，empty方法测试堆栈是否为空，search方法检测一个元素在堆栈中的位置。Stack刚创建后是空栈。Map接口　　请注意，Map没有继承Collection接口，Map提供key到value的映射。一个Map中不能包含相同的key，每个key只能映射一个value。Map接口提供3种集合的视图，Map的内容可以被当作一组key集合，一组value集合，或者一组key-value映射。Hashtable类　　Hashtable继承Map接口，实现一个key-value映射的哈希表。任何非空（non-null）的对象都可作为key或者value。　　添加数据使用put(key, value)，取出数据使用get(key)，这两个基本操作的时间开销为常数。Hashtable通过initial capacity和load factor两个参数调整性能。通常缺省的load factor 0.75较好地实现了时间和空间的均衡。增大load factor可以节省空间但相应的查找时间将增大，这会影响像get和put这样的操作。使用Hashtable的简单示例如下，将1，2，3放到Hashtable中，他们的key分别是”one”，”two”，”three”：　　　　Hashtable numbers = new Hashtable();　　　　numbers.put(“one”, new Integer(1));　　　　numbers.put(“two”, new Integer(2));　　　　numbers.put(“three”, new Integer(3));　　要取出一个数，比如2，用相应的key：　　　　Integer n = (Integer)numbers.get(“two”);　　　　System.out.println(“two = ” + n);　　由于作为key的对象将通过计算其散列函数来确定与之对应的value的位置，因此任何作为key的对象都必须实现hashCode和equals方法。hashCode和equals方法继承自根类Object，如果你用自定义的类当作key的话，要相当小心，按照散列函数的定义，如果两个对象相同，即obj1.equals(obj2)=true，则它们的hashCode必须相同，但如果两个对象不同，则它们的hashCode不一定不同，如果两个不同对象的hashCode相同，这种现象称为冲突，冲突会导致操作哈希表的时间开销增大，所以尽量定义好的hashCode()方法，能加快哈希表的操作。　　如果相同的对象有不同的hashCode，对哈希表的操作会出现意想不到的结果（期待的get方法返回null），要避免这种问题，只需要牢记一条：要同时复写equals方法和hashCode方法，而不要只写其中一个。　　Hashtable是同步的。HashMap类　　HashMap和Hashtable类似，不同之处在于HashMap是非同步的，并且允许null，即null value和null key。，但是将HashMap视为Collection时（values()方法可返回Collection），其迭代子操作时间开销和HashMap的容量成比例。因此，如果迭代操作的性能相当重要的话，不要将HashMap的初始化容量设得过高，或者load factor过低。WeakHashMap类　　WeakHashMap是一种改进的HashMap，它对key实行“弱引用”，如果一个key不再被外部所引用，那么该key可以被GC回收。总结　　如果涉及到堆栈，队列等操作，应该考虑用List，对于需要快速插入，删除元素，应该使用LinkedList，如果需要快速随机访问元素，应该使用ArrayList。　　如果程序在单线程环境中，或者访问仅仅在一个线程中进行，考虑非同步的类，其效率较高，如果多个线程可能同时操作一个类，应该使用同步的类。　　要特别注意对哈希表的操作，作为key的对象要正确复写equals和hashCode方法。　　尽量返回接口而非实际的类型，如返回List而非ArrayList，这样如果以后需要将ArrayList换成LinkedList时，客户端代码不用改变。这就是针对抽象编程。同步性Vector是同步的。这个类中的一些方法保证了Vector中的对象是线程安全的。而ArrayList则是异步的，因此ArrayList中的对象并不是线程安全的。因为同步的要求会影响执行的效率，所以如果你不需要线程安全的集合那么使用ArrayList是一个很好的选择，这样可以避免由于同步带来的不必要的性能开销。数据增长从内部实现机制来讲ArrayList和Vector都是使用数组(Array)来控制集合中的对象。当你向这两种类型中增加元素的时候，如果元素的数目超出了内部数组目前的长度它们都需要扩展内部数组的长度，Vector缺省情况下自动增长原来一倍的数组长度，ArrayList是原来的50%,所以最后你获得的这个集合所占的空间总是比你实际需要的要大。所以如果你要在集合中保存大量的数据那么使用Vector有一些优势，因为你可以通过设置集合的初始化大小来避免不必要的资源开销。使用模式在ArrayList和Vector中，从一个指定的位置（通过索引）查找数据或是在集合的末尾增加、移除一个元素所花费的时间是一样的，这个时间我们用O(1)表示。但是，如果在集合的其他位置增加或移除元素那么花费的时间会呈线形增长：O(n-i)，其中n代表集合中元素的个数，i代表元素增加或移除元素的索引位置。为什么会这样呢？以为在进行上述操作的时候集合中第i和第i个元素之后的所有元素都要执行位移的操作。这一切意味着什么呢？这意味着，你只是查找特定位置的元素或只在集合的末端增加、移除元素，那么使用Vector或ArrayList都可以。如果是其他操作，你最好选择其他的集合操作类。比如，LinkList集合类在增加或移除集合中任何位置的元素所花费的时间都是一样的?O(1)，但它在索引一个元素的使用缺比较慢－O(i),其中i是索引的位置.使用ArrayList也很容易，因为你可以简单的使用索引来代替创建iterator对象的操作。LinkList也会为每个插入的元素创建对象，所有你要明白它也会带来额外的开销。最后，在《Practical Java》一书中Peter Haggar建议使用一个简单的数组（Array）来代替Vector或ArrayList。尤其是对于执行效率要求高的程序更应如此。因为使用数组(Array)避免了同步、额外的方法调用和不必要的重新分配空间的操作。

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的复制默认节点就是三节点以上的复制集群，当数据到达主节点之后会马上同步到从节点上去。