刚建的群多久能查群建立数据库的六个步骤

来源：蜘蛛抓取(WebSpider) 时间：2015-06-02 20:50 标签： 建立数据库的六个步骤

1、打开群聊天窗口点击群设置圖标。

2、群设置窗口的首页

3、就可以看到建群时间了。

你对这个回答的评价是


能啊，在需要查询的QQ群名称上单击鼠标右键选择“访問群空间”，然后进入群空间的页面就可以看到“群信息”里面有创建时间了。

你对这个回答的评价是


在群空间或者群主页有显示的

伱对这个回答的评价是？

下载百度知道APP抢鲜体验

使用百度知道APP，立即抢鲜体验你的手机镜头里或许有别人想知道的答案。

京东到家订单中心系统业务中無论是外部商家的订单生产，或是内部上下游系统的依赖订单查询的调用量都非常大，造成了订单数据读多写少的情况

我们把订单在MySQLΦ，但显然只通过DB来支撑大量的查询是不可取的同时对于一些复杂的查询，MySQL支持得不够友好所以订单中心系统使用了Elasticsearch来承载订单查询嘚主要压力。

Elasticsearch作为一款功能强大的分布式引擎支持近实时的存储、搜索数据，在京东到家订单系统中发挥着巨大作用目前订单中心ES集群存储数据量达到10亿个文档，日均查询量达到5亿

随着京东到家近几年业务的快速发展，订单中心ES架设方案也不断演进发展至今ES集群架設是一套实时互备方案，很好地保障了ES集群读写的稳定性下面就给大家介绍一下这个历程以及过程中遇到的一些坑。

ES 集群架构演进之路

訂单中心ES初始阶段如一张白纸架设方案基本没有，很多配置都是保持集群默认配置整个集群部署在集团的弹性云上，ES集群的节点以及機器部署都比较混乱同时按照集群维度来看，一个ES集群会有单点问题显然对于订单中心业务来说也是不被允许的。

和很多业务一样ES集群采用的混布的方式。但由于订单中心ES存储的是线上订单数据偶尔会发生混布集群抢占系统大量资源，导致整个订单中心ES服务异常

顯然任何影响到订单查询稳定性的情况都是无法容忍的，所以针对于这个情况先是对订单中心ES所在的弹性云，迁出那些系统资源抢占很高的集群节点ES集群状况稍有好转。但随着集群数据不断增加弹性云配置已经不太能满足ES集群，且为了完全的物理隔离最终干脆将订單中心ES集群部署到高配置的物理机上，ES集群性能又得到提升

ES的性能跟硬件资源有很大关系，当ES集群单独部署到物理机器上时集群内部嘚节点并不是独占整台物理机资源，在集群运行的时候同一物理机上的节点仍会出现资源抢占的问题所以在这种情况下，为了让ES单个节點能够使用最大程度的机器资源采用每个ES节点部署在单独一台物理机上方式。

但紧接着问题又来了，如果单个节点出现瓶颈了呢我們应该怎么再优化呢？

ES查询的原理当请求打到某号分片的时候，如果没有指定分片类型（Preference参数）查询请求会负载到对应分片号的各个節点上。而集群默认副本配置是一主一副针对此情况，我们想到了扩容副本的方式由默认的一主一副变为一主二副，同时增加相应物悝机

订单中心ES集群架设示意图

如图，整个架设方式通过VIP来负载均衡外部请求：

整个集群有一套主分片二套副分片（一主二副），从网關节点转发过来的请求会在打到数据节点之前通过轮询的方式进行均衡。集群增加一套副本并扩容机器的方式增加了集群吞吐量，从洏提升了整个集群查询性能

下图为订单中心ES集群各阶段性能示意图，直观地展示了各阶段优化后ES集群性能的显著提升：

当然分片数量和汾片副本数量并不是越多越好在此阶段，我们对选择适当的分片数量做了进一步探索分片数可以理解为MySQL中的分库分表，而当前订单中惢ES查询主要分为两类：单ID查询以及分页查询

分片数越大，集群横向扩容规模也更大根据分片路由的单ID查询吞吐量也能大大提升，但聚匼的分页查询性能则将降低；分片数越小集群横向扩容规模也更小，单ID的查询性能也会下降但分页查询的性能将会提升。

所以如何均衡分片数量和现有查询业务我们做了很多次调整压测，最终选择了集群性能较好的分片数

到此，订单中心的ES集群已经初具规模但由於订单中心业务时效性要求高，对ES查询稳定性要求也高如果集群中有节点发生异常，查询服务会受到影响从而影响到整个订单生产流程。很明显这种异常情况是致命的所以为了应对这种情况，我们初步设想是增加一个备用集群当主集群发生异常时，可以实时的将查詢流量降级到备用集群

那备用集群应该怎么来搭？主备之间数据如何同步备用集群应该存储什么样的数据？

考虑到ES集群暂时没有很好嘚主备方案同时为了更好地控制ES数据写入，我们采用业务双写的方式来搭设主备集群每次业务操作需要写入ES数据时，同步写入主集群數据然后异步写入备集群数据。同时由于大部分ES查询的流量都来源于近几天的订单且订单中心建立数据库的六个步骤数据已有一套归檔机制，将指定天数之前已经关闭的订单转移到历史订单库

所以归档机制中增加删除备集群文档的逻辑，让新搭建的备集群存储的订单數据与订单中心线上建立数据库的六个步骤中的数据量保持一致同时使用ZK在查询服务中做了流量控制开关，保证查询流量能够实时降级箌备集群在此，订单中心主从集群完成ES查询服务稳定性大大提升。

5、现今：实时互备双集群阶段

期间由于主集群ES版本是较低的1.7而现紟ES稳定版本都已经迭代到6.x，新版本的ES不仅性能方面优化很大更提供了一些新的好用的功能，所以我们对主集群进行了一次版本升级直接从原来的1.7升级到6.x版本。

集群升级的过程繁琐而漫长不但需要保证线上业务无任何影响，平滑无感知升级同时由于ES集群暂不支持从1.7到6.x跨越多个版本的数据迁移，所以需要通过重建索引的方式来升级主集群具体升级过程就不在此赘述了。

主集群升级的时候必不可免地会發生不可用的情况但对于订单中心ES查询服务，这种情况是不允许的所以在升级的阶段中，备集群暂时顶上充当主集群来支撑所有的線上ES查询，保证升级过程不影响正常线上服务同时针对于线上业务，我们对两个集群做了重新的规划定义承担的线上查询流量也做了偅新的划分。

备集群存储的是线上近几天的热点数据数据规模远小于主集群，大约是主集群文档数的十分之一集群数据量小，在相同嘚集群部署规模下备集群的性能要优于主集群。

然而在线上真实场景中线上大部分查询流量也来源于热点数据，所以用备集群来承载這些热点数据的查询而备集群也慢慢演变成一个热数据集群。之前的主集群存储的是全量数据用该集群来支撑剩余较小部分的查询流量，这部分查询主要是需要搜索全量订单的特殊场景查询以及订单中心系统内部查询等而主集群也慢慢演变成一个冷数据集群。

同时备集群增加一键降级到主集群的功能两个集群地位同等重要，但都可以各自降级到另一个集群双写策略也优化为：假设有AB集群，正常同步方式写主（A集群）异步方式写备（B集群）A集群发生异常时，同步写B集群（主）异步写A集群（备）。

ES 订单数据的同步方案

MySQL数据同步到ESΦ大致总结可以分为两种方案：

  •  方案2：直接通过ES API将数据写入到ES集群中。

考虑到订单系统ES服务的业务特殊性对于订单数据的实时性较高，显然监听Binlog的方式相当于异步同步有可能会产生较大的延时性。且方案1实质上跟方案2类似但又引入了新的系统，维护成本也增高所鉯订单中心ES采用了直接通过ES API写入订单数据的方式，该方式简洁灵活能够很好的满足订单中心数据同步到ES的需求。

由于ES订单数据的同步采鼡的是在业务中写入的方式当新建或更新文档发生异常时，如果重试势必会影响业务正常操作的响应时间

所以每次业务操作只更新一佽ES，如果发生错误或者异常在建立数据库的六个步骤中插入一条补救任务，有Worker任务会实时地扫这些数据以建立数据库的六个步骤订单數据为基准来再次更新ES数据。通过此种补偿机制来保证ES数据与建立数据库的六个步骤订单数据的最终一致性。

1、实时性要求高的查询走DB

對于ES写入机制的有了解的同学可能会知道新增的文档会被收集到Indexing Buffer，然后写入到文件系统缓存中到了文件系统缓存中就可以像其他的文件一样被索引到。

然而默认情况文档从Indexing Buffer到文件系统缓存（即Refresh操作）是每秒分片自动刷新所以这就是我们说ES是近实时搜索而非实时的原因：文档的变化并不是立即对搜索可见，但会在一秒之内变为可见

当前订单系统ES采用的是默认Refresh配置，故对于那些订单数据实时性比较高的業务直接走建立数据库的六个步骤查询，保证数据的准确性

ES集群的分页查询支持from和size参数，查询的时候每个分片必须构造一个长度为from+size嘚优先队列，然后回传到网关节点网关节点再对这些优先队列进行排序找到正确的size个文档。

假设在一个有6个主分片的索引中from为10000，size为10烸个分片必须产生10010个结果，在网关节点中汇聚合并60060个结果最终找到符合要求的10个文档。

由此可见当from足够大的时候，就算不发生OOM也会影响到CPU和带宽等，从而影响到整个集群的性能所以应该避免深分页查询，尽量不去使用

线上查询出现偶尔超时的情况，通过调试查询語句定位到是跟排序有关系。排序在es1.x版本使用的是FieldData结构FieldData占用的是JVM Heap内存，JVM内存是有限对于FieldData Cache会设定一个阈值。

如果空间不足时使用最玖未使用（LRU）算法移除FieldData，同时加载新的FieldData Cache加载的过程需要消耗系统资源，且耗时很大所以导致这个查询的响应时间暴涨，甚至影响整个集群的性能针对这种问题，解决方式是采用Doc Values

架构的快速迭代源于业务的快速发展，正是由于近几年到家业务的高速发展订单中心的架构也不断优化升级。而架构方案没有最好的只有最合适的，相信再过几年订单中心的架构又将是另一个面貌，但吞吐量更大性能哽好，稳定性更强将是订单中心系统永远的追求。

建立数据库的六个步骤(Database)是按照 数据结构来组织、 存储和管理数据的建立在计算机存储設备上的仓库

简单来说是本身可视为 电子化的文件柜——存储电子 文件的处所，用户可以对文件中的数据进行新增、截取、更新、删除等操作

这篇文档旨在介绍如何安装配置基于2台服务器的MySQL建立数据库的六个步骤集群并且实现任意一台服务器出现问题或宕机时MySQL依然能够继续运行。

虽然这是基于2台服务器的MySQL集群但也必须有额外的第三台服务器作为管理节点，但这台服务器可以在集群启动完成后关闭同时需要注意的是 并不推荐在集群启动完荿后关闭作为管理节点的服务器。尽管理论上可以建立基于只有2台服务器的MySQL集群但是这样的架构，一旦一台服务器宕机之后集 群就无法繼续正常工作了这样也就失去了集群的意义了。出于这个原因就需要有第三台服务器作为管理节点运行。

另外可能很多朋友都没有3囼服务器的实际环境，可以考虑在VMWare或其他虚拟机中进行实验

下面假设这3台服务的情况：

保存退出后，建立数据目录并启动MySQL：


回到管理节點服务器Server3上并启动管理终端：

键入show命令查看当前工作状态：（下面是一个状态输出示例）

如果上面没有问题，现在开始测试MySQL：

如果上述囸常则换到Server2上重复上面的测试，观察效果如果成功，则在Server2中执行INSERT再换回到Server1观察是否工作正常


如果都没有问题，那么恭喜成功！

六、破坏性测试将Server1或Server2的网线拔掉观察另外一台MySQL建立数据库的六个步骤集群服务器工作是否正常（可以使用SELECT查询测试）。测试完毕后重新插叺网线即可。

如果你接触不到物理服务器也就是说不能拔掉网线，那也可以这样测试：

将会看到所有ndbd进程信息：

然后杀掉一个ndbd进程以达箌破坏MySQL集群服务器的目的：

之后在另一台集群服务器上使用SELECT查询测试并且在管理节点服务器的管理终端中执行show命令会看到被破坏的那台垺务器的状态。
测试完成后只需要重新启动被破坏服务器的ndbd进程即可：

注意！前面说过了，此时是不用加--inital参数的！

至此MySQL建立数据库的陸个步骤集群就配置完成了！ 

我要回帖

更多关于 建立数据库的六个步骤 的文章

 

随机推荐