partition

高效使用STL 参考：http://blog.jobbole.com/99115/ 仅仅是个选择的问题，都是STL，可能写出来的效率相差几倍； 熟悉以下条款，高效的使用STL； 当对象很大时，建立指针的容器而不是对象的容器 1）STL基于拷贝的方式的来工作，任何需要放入STL中的元素，都会被复制； 这也好理解，STL工作的容器是在堆内开辟的一块新空间，而我们自己的变量一般存放在函数栈或另一块堆空间中；为了能够完全控制STL自己的元素，为了能在自己的地盘随心干活；这就涉及到复制； 而如果复制的对象很大，由复制带来的性能代价也不小 ； 对于大对象的操作，使用指针来代替对象能消除这方面的代价； 2）只涉及到指针拷贝操作， 没有额外类的构造函数和赋值构造函数的调用； vecttor vt1; vt1.push_bach(myBigObj); vecttor vt2; vt2.push_bach(new BigObj()); 注意事项： 1）容器销毁前需要自行销毁指针所指向的对象；否则就造成了内存泄漏； 2）使用排序等算法时，需要构造基于对象的比较函数，如果使用默认的比较函数，其结果是基于指针大小的比较，而不是对象的比较； 用empty() 代替size()来检查是否为空 因为对于list，size()会遍历每一个元素来确定大小，时间复杂度 o（n），线性时间；而empty总是保证常数时间；

面试题 如何保证消息的顺序性？ 面试官心理分析 其实这个也是用 MQ 的时候必问的话题，第一看看你了不了解顺序这个事儿？第二看看你有没有办法保证消息是有顺序的？这是生产系统中常见的问题。 面试题剖析 我举个例子，我们以前做过一个 mysql binlog 同步的系统，压力还是非常大的，日同步数据要达到上亿，就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去（mysql -> mysql）。常见的一点在于说比如大数据 team，就需要同步一个 mysql 库过来，对公司的业务系统的数据做各种复杂的操作。 你在 mysql 里增删改一条数据，对应出来了增删改 3 条 binlog 日志，接着这三条 binlog 发送到 MQ 里面，再消费出来依次执行，起码得保证人家是按照顺序来的吧？不然本来是：增加、修改、删除；你楞是换了顺序给执行成删除、修改、增加，不全错了么。 本来这个数据同步过来，应该最后这个数据被删除了；结果你搞错了这个顺序，最后这个数据保留下来了，数据同步就出错了。 先看看顺序会错乱的俩场景： RabbitMQ ：一个 queue，多个 consumer。比如，生产者向 RabbitMQ 里发送了三条数据，顺序依次是 data1/data2/data3，压入的是 RabbitMQ 的一个内存队列。有三个消费者分别从 MQ 中消费这三条数据中的一条

1.集群高可靠 ①搭建kafka集群（略） ②重点配置项（每个broker配置相同，只有broker.id不一样） broker.id =1 当前机器在集群中的唯一标识，和zookeeper的myid性质一样 listeners= PLAINTEXT://10.22.0.13:9092 最好用真实的IP advertised.listeners= PLAINTEXT://10.22.0.13:9092 最好用真实的IP hostname,port配置过时 num.partitions=3 新建topic 默认分区数 default.replication.factor=3 新建topic 默认副本集数 offsets.topic.replication.factor=3 副本集因子 （必须配置为大于1，小于或者等于broker数，不然当消费者的协同节点broker宕机了，不会重新选举，导致消费者dead，达不到集群高可靠目的） zookeeper.connect=10.22.0.13:2182,10.22.0.14:2182,10.22.0.15:2182 zookeeper地址 log.dirs=/home/txc/kafka1/kafkalogs kafka数据日志保存路径 2.消息至少消费一次 消费者默认情况下，enable.auto.commit=true

参考链接： https://hexeract.wordpress.com/2012/04/30/how-to-expand-the-root-filesystem-of-a-11-10-ubuntu-running-inside-vmware-player/ http://imcczy.com/how-to-expand-the-root-filesystem-in-vmware.html http://blog.csdn.net/ouyang_peng/article/details/53261599 查看需要修改的硬盘 cmd 到 VirtualBox 的安装目录 12 cd VirtualBoxVBoxManage list hdds 转换成vdi格式 已是 vdi 格式的则略过。 vmdk 转 vdi 1 VBoxManage clonehd D:Softwares...src.vmdk D:Softwares...dst.vdi --format VDI vdi 转 vmdk 1 VBoxManage clonehd D:Softwares...src.vdi D:Softwares...dst.vmdk --format VMDK 修改硬盘镜像文件 123 VBoxManage modifyhd D:Softwares...dst.vdi --resize 92160#

在文章 《Nebula 架构剖析系列（一）图数据库的存储设计》 中，我们提过分布式图存储的管理由 Meta Service 来统一调度，它记录了所有 partition 的分布情况，以及当前机器的状态。当 DBA 增减机器时，只需要通过 console 输入相应的指令，Meta Service 便能够生成整个 Balance 计划并执行。而之所以没有采用完全自动 Balance 的方式，主要是为了减少数据搬迁对于线上服务的影响，Balance 的时机由用户自己控制。 在本文中我们将着重讲解在存储层如何实现数据和服务的负载平衡。 简单回顾一下， Nebula Graph 的服务可分为 graph，storage，meta。本文主要描述对于存储层（storage）的数据和服务的 balance。这些都是通过 Balance 命令来实现的：Balance 命令有两种，一种需要迁移数据，命令为 BALANCE DATA ；另一种不需要迁移数据，只改变 partition 的 raft-leader 分布（负载均衡），命令为 BALANCE LEADER 。 本文目录 Balance 机制浅析 集群数据迁移 Step 1：准备工作 Step 1.1 查看现有集群状态 Step 1.2 创建图空间 Step 2 加入新实例 Step 3 迁移数据 Step 4 假如要中途停止 balance

Getting Start 下载 http://kafka.apache.org/ 优点和应用场景 Kafka消息驱动，符合发布-订阅模式，优点和应用范围都共通 发布-订阅模式优点 解耦合 ： 两个应用不需要相互调用 可扩展性 ： 消费者的个数可实时扩展 实时性 ： 消费者能实时的获取生产者发布的事件 高效 ：减少由于多个消费者请求数据造成的数据计算带来的资源消耗 异步通讯 ：发布-订阅模式是天生的异步通讯 Kafka其他优点 持久化 ： 消息丢失的可控性极高 高性能 ： 磁盘顺序读写性能比内存随机读写还高，每秒10万条消息 高吞吐量 ：每秒上百MB的吞吐量 顺序性 发布-订阅模式应用范围 适合数据一被生产，就需要被处理的情况 适合数据具有潜在消费者的情况 适合无论有没有消费者，数据都在生产的情况 不适合对数据的处理时间有特殊限定的情况 应用场景 最为消息中间件，实现消息队列和消息的发布-订阅，消息驱动的服务 数据总线，一对多的模式 日志收集，消息中间件的一种应用 数据库主从同步 核心概念 Broker 一个Kafka server就是一个Broker 一般情况下，一个Broker独占一台服务器，发挥微服务的优势 服务器资源有限的情况下，需要设计出Broker/Topic/Partition/Replica的最优分配策略，从而充分利用服务器资源 一个broker可以有多个topic

kafka是什么 kafka中文官网 摘自官网: Kafka® is used for building real-time data pipelines and streaming apps. It is horizontally scalable, fault-tolerant, wicked fast, and runs in production in thousands of companies. 意思就是：kafka是用于构建实时数据管道和流应用程序。具有横向扩展，容错，wicked fast（变态快）等优点，并已在成千上万家公司运行。 在我认为：kafka就是一个消息中间件 什么又是消息中间件呢？ 可与OA、ERP集成的免费消息中间件Active Messenger（简称AM）是一款非常实用的企业即时通讯软件。系统提供免费的消息中间件（以com组件的方式提供），开放给第三方程序使用。 以上是百度解释 就是我们用a这个软件的时候要用c这个里面的东西，但是我们没有去直接调用，而是通过b这个软件去使用c里面的东西 常见的消息中间件产品: 1.ActiveMQ 　　ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。我们在本次课程中介绍

Kafka有两种模式： 点对点模式：消费者主动从Kafka中定时轮询的拉取数据，一条数据只会发送给customer group中的一个customer进行消费。 发布订阅者模式：kafka主动推送数据到所有订阅了该类信息的客户端。 Kafka中通过控制Customer的参数{group.id}来决定kafka是什么数据消费模式，如果所有消费者的该参数值是相同的，那么此时的kafka就是队列模式，数据只会发送到一个customer，此时Kafka类似于负载均衡；否则就是发布订阅模式； 在队列模式下，可能会触发Kafka的Consumer Rebalance kafka是依赖Zookeeper的，kafka中节点的状态信息和消费者的消费消息的状态信息会保存在zookeeper中，且zookeeper只保存这两点信息 kafka中存在几个概念：Broker、Topic、Partition Broker：为一个节点，每开启一个kafka服务就会有一个Broker Topic：为主题。kafka中消息是分类别的，kafka是通过topic来为消息分类的，每一个topic代表着一种消息类型。同一个topic可以存在于多个Broker中 Partition：为分区，分区存在于topic中，每个topic中会存在多个分区。在Kafka中分区是操作的最小单元

第 3 章 Kafka 工作流程分析 Kafka核心组成 3 . 1 Kafka 生产过程分析 3.1 .1 写入方式 producer 采用 推（push） 模式将消息发布到 broker ，每条消息都被 追加（append） 到 分区（patition） 中 ，属于 顺序写磁盘 （顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。 3.1.2 分区 （ Partition ） 消息发送时都被发送到一个 topic ，其本质就是一个目录，而 topic 是由一些 Partition Logs( 分区日志 ) 组成 ， 其组织结构如下图所示： 我们可以看到，每个 Partition 中的消息都是 有序 的，生产的消息被不断追加到 Partition log 上，其中的每一个消息都被赋予了一个唯一的 offset 值 。 1 ）分区的 原因 （ 1 ） 方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 topic 又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据了； （ 2 ） 可以提高并发，因为可以以 Partition 为单位读写了。 2） 分区的原则 （ 1 ） 指定了 patition ，则直接使用 ； （ 2 ） 未指定 patition 但指定 key ，通过对 key 的 value 进行 hash

美图欣赏： 自己画的一张流程图： 1）Producer ：消息生产者，就是向kafka broker发消息的客户端。 2）Consumer ：消息消费者，向kafka broker取 消息的客户端 3）Topic ：可以理解为一个队列。 4） Consumer Group （CG）：kafka提供的可扩展且具有容错性的消费者机制。既然是一个组，那么组内必然可以有多个消费者或消费者实例(consumer instance)，它们共享一个公共的ID，即group ID。组内的所有消费者协调在一起来消费订阅主题(subscribed topics)的所有分区(partition)。当然，每个分区只能由同一个消费组内的一个consumer来消费。 5）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。 6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序。 7