减轻墓碑带来的麻烦 好了，现在我们已经明白为什么我们要用墓碑，我们对墓碑也有一个大致的了解了。现在让我们看看墓碑会引起哪些潜在的麻烦，我们可以采取哪些措施来减轻这些麻烦。 首先一个很显而易见的事情就是墓碑没有让数据被删掉，反而增加了存储。我们需要删除这些墓碑以腾出磁盘空间，并且限制读出无用数据的大小，以降低时延和提高资源利用率。这个事情就发生在接下来你看到的压实的过程。 压实（Compactions） 当我们读取某一行数据的时候，为了读取到这一行数据的所有片段，我们翻阅的SSTables阅读，读时延就越大。因此我们有必要把这些片段通过压实的过程把他们合并，以获得更低的读时延。这个过程包括把合适的目标也清除掉，如我所愿的持续释放可用的空间。 压实的过程是通过合并来自多个sstable的row片段，去删除满足一定条件的墓碑。有些条件是在表的schema中指定的，而且是可以优化可调节的，比如gc_grace_seconds参数，有些条件是cassandra内部的，代码里写死的，这是为了保证数据持久化和一致性。要保证没有参与当前压实的sstable（重叠sstables）里没有新的数据片段，这是防止墓碑被清掉以后，数据又出现成为僵尸数据的必要条件。 再看上面的例子，经过删除和flush以后，表数据目录大致如下： alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/ total 360 drwxr-xr-x 43 alain staff 1462 Jun 17 11:39 . drwxr-xr-x 3 alain staff 102 Jun 16 20:25 .. drwxr-xr-x 2 alain staff 68 Jun 16 17:05 backups -rw-r–r– 1 alain staff 43 Jun 17 11:13 mb-10-big-CompressionInfo.db -rw-r–r– 1 alain staff 43 Jun 17 11:13 mb-10-big-Data.db -rw-r–r– 1 alain staff 10 Jun 17 11:13 mb-10-big-Digest.crc32 -rw-r–r– 1 alain staff 16 Jun 17 11:13 mb-10-big-Filter.db -rw-r–r– 1 alain staff 9 Jun 17 11:13 mb-10-big-Index.db -rw-r–r– 1 alain staff 4701 Jun 17 11:13 mb-10-big-Statistics.db -rw-r–r– 1 alain staff 59 Jun 17 11:13 mb-10-big-Summary.db -rw-r–r– 1 alain staff 92 Jun 17 11:13 mb-10-big-TOC.txt -rw-r–r– 1 alain staff 43 Jun 17 11:33 mb-11-big-CompressionInfo.db -rw-r–r– 1 alain staff 53 Jun 17 11:33 mb-11-big-Data.db -rw-r–r– 1 alain staff 9 Jun 17 11:33 mb-11-big-Digest.crc32 -rw-r–r– 1 alain staff 16 Jun 17 11:33 mb-11-big-Filter.db -rw-r–r– 1 alain staff 9 Jun 17 11:33 mb-11-big-Index.db -rw-r–r– 1 alain staff 4611 Jun 17 11:33 mb-11-big-Statistics.db -rw-r–r– 1 alain staff 59 Jun 17 11:33 mb-11-big-Summary.db -rw-r–r– 1 alain staff 92 Jun 17 11:33 mb-11-big-TOC.txt -rw-r–r– 1 alain staff 43 Jun 17 11:33 mb-12-big-CompressionInfo.db -rw-r–r– 1 alain staff 42 Jun 17 11:33 mb-12-big-Data.db -rw-r–r– 1 alain staff 10 Jun 17 11:33 mb-12-big-Digest.crc32 -rw-r–r– 1 alain staff 16 Jun 17 11:33 mb-12-big-Filter.db -rw-r–r– 1 alain staff 9 Jun 17 11:33 mb-12-big-Index.db -rw-r–r– 1 alain staff 4611 Jun 17 11:33 mb-12-big-Statistics.db -rw-r–r– 1 alain staff 59 Jun 17 11:33 mb-12-big-Summary.db -rw-r–r– 1 alain staff 92 Jun 17 11:33 mb-12-big-TOC.txt -rw-r–r– 1 alain staff 43 Jun 17 11:39 mb-13-big-CompressionInfo.db -rw-r–r– 1 alain staff 32 Jun 17 11:39 mb-13-big-Data.db -rw-r–r– 1 alain staff 9 Jun 17 11:39 mb-13-big-Digest.crc32 -rw-r–r– 1 alain staff 16 Jun 17 11:39 mb-13-big-Filter.db -rw-r–r– 1 alain staff 11 Jun 17 11:39 mb-13-big-Index.db -rw-r–r– 1 alain staff 4591 Jun 17 11:39 mb-13-big-Statistics.db -rw-r–r– 1 alain staff 65 Jun 17 11:39 mb-13-big-Summary.db -rw-r–r– 1 alain staff 92 Jun 17 11:39 mb-13-big-TOC.txt -rw-r–r– 1 alain staff 43 Jun 17 11:12 mb-9-big-CompressionInfo.db -rw-r–r– 1 alain staff 127 Jun 17 11:12 mb-9-big-Data.db -rw-r–r– 1 alain staff 10 Jun 17 11:12 mb-9-big-Digest.crc32 -rw-r–r– 1 alain staff 16 Jun 17 11:12 mb-9-big-Filter.db -rw-r–r– 1 alain staff 20 Jun 17 11:12 mb-9-big-Index.db -rw-r–r– 1 alain staff 4740 Jun 17 11:12 mb-9-big-Statistics.db -rw-r–r– 1 alain staff 61 Jun 17 11:12 mb-9-big-Summary.db -rw-r–r– 1 alain staff 92 Jun 17 11:12 mb-9-big-TOC.txt ...

让我们现在看看各种类型的删除： cell删除 在cassandra存储引擎里，一指定行里面的一列就叫做cell。 删除某一行的某一个cell如下： DELETE crates FROM tlp_lab.tombstones WHERE fruit=‘apple’ AND date =‘20160617’; 这一行的crates列就会显示为“null”： alain$ echo “SELECT * FROM tlp_lab.tombstones LIMIT 100;” | cqlsh fruit | date | crates ———+———-+—————– apple | 20160616 | {1, 2, 3, 4, 5} apple | 20160617 | null pickles | 20160616 | {6, 7, 8} (3 rows) 执行flush以后，我们会得到一个新的sstable在磁盘上: mb-6-big alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/ total 144 drwxr-xr-x 19 alain staff 646 Jun 16 21:12 . drwxr-xr-x 3 alain staff 102 Jun 16 20:25 .. drwxr-xr-x 2 alain staff 68 Jun 16 17:05 backups -rw-r–r– 1 alain staff 43 Jun 16 20:53 mb-5-big-CompressionInfo.db -rw-r–r– 1 alain staff 127 Jun 16 20:53 mb-5-big-Data.db -rw-r–r– 1 alain staff 10 Jun 16 20:53 mb-5-big-Digest.crc32 -rw-r–r– 1 alain staff 16 Jun 16 20:53 mb-5-big-Filter.db -rw-r–r– 1 alain staff 20 Jun 16 20:53 mb-5-big-Index.db -rw-r–r– 1 alain staff 4740 Jun 16 20:53 mb-5-big-Statistics.db -rw-r–r– 1 alain staff 61 Jun 16 20:53 mb-5-big-Summary.db -rw-r–r– 1 alain staff 92 Jun 16 20:53 mb-5-big-TOC.txt -rw-r–r– 1 alain staff 43 Jun 16 21:12 mb-6-big-CompressionInfo.db -rw-r–r– 1 alain staff 43 Jun 16 21:12 mb-6-big-Data.db -rw-r–r– 1 alain staff 10 Jun 16 21:12 mb-6-big-Digest.crc32 -rw-r–r– 1 alain staff 16 Jun 16 21:12 mb-6-big-Filter.db -rw-r–r– 1 alain staff 9 Jun 16 21:12 mb-6-big-Index.db -rw-r–r– 1 alain staff 4701 Jun 16 21:12 mb-6-big-Statistics.db -rw-r–r– 1 alain staff 59 Jun 16 21:12 mb-6-big-Summary.db -rw-r–r– 1 alain staff 92 Jun 16 21:12 mb-6-big-TOC.txt ...

保存墓碑（原文Tombstones to the rescue 墓碑营救?） 在Cassandra语境中，墓碑是一种特殊的数据和普通数据一样存储，一个删除操作，就是写入一个墓碑。当Cassandra读取数据的时候，它会合并这些内存里或者磁盘上写入的数据行。然后使用一种最新写入胜出(LWW)算法选择出正确的数据，不管它是个标准写入的数据，还是一个墓碑。 举例： 我们看下接下来的例子，背景是Cassandra 3.7集群，有3个节点(通过ccm创建的,译者注：ccm是个脚本程序可以快速的删除创建一个小Cassandra集群,github地址是：https://github.com/pcmanus/ccm) CREATE KEYSPACE tlp_lab WITH replication = {‘class’: ‘NetworkTopologyStrategy’, ‘datacenter1’ : 3}; CREATE TABLE tlp_lab.tombstones (fruit text, date text, crates set<int>, PRIMARY KEY (fruit, date)); 插入一些数据，每天创建一些水果（译者注：表里的字段的含义），如下： INSERT INTO tlp_lab.tombstones (fruit, date, crates) VALUES (‘apple’, ‘20160616’, {1,2,3,4,5}); INSERT INTO tlp_lab.tombstones (fruit, date, crates) VALUES (‘apple’, ‘20160617’, {1,2,3}); INSERT INTO tlp_lab.tombstones (fruit, date, crates) VALUES (‘pickles’, ‘20160616’, {6,7,8}) USING TTL 2592000; 下面就是我们存储的数据： alain$ echo “SELECT * FROM tlp_lab.tombstones LIMIT 100;” | cqlsh ...

分布式删除的难题 考虑上面的情况，强一致性是必须的，让我们暂且忘掉墓碑这个东西，假设cassandra删除数据不使用墓碑。如果一次删除操作在一个节点上失败了（总共3个节点，副本为3， RF=3).整个删除操作仍然被认为成功的（因为有两个节点应答成功，使用CL.QUORUM一致性）。接下来如果读发生在该节点上就会变的不明确，因为结果返回是空，还是返回数据，没有办法确定哪一种是正确的。Cassandra总是任务返回数据是对的，那就会发生删除的数据又出现了的事情，这些数据可以叫"僵尸"或者"鬼"，并且他们的表现是不可预见的 注意：这个问题没有完全解决，即便使用了墓碑，所以假设你的集群有删除操作的话我们还要有如下操作: Cassandra运维人员必须在每个gc_grace_seconds周期内对整个集群进行repair操作。 从一个Cassandra节点的视角看待删除 Cassandra使用一旦写入就不再改变的文件来存储数据，像前面描述，墓碑的目的就是为了解决从这样的系统中删除数据的困难的。 Cassanda的一个特种就是使用了一种日志结构合并树（LSM tree），然而大多数关系型数据库（RDBMS）是使用的B树（B-tree)。这样说你可能更容易理解:记住Cassandra写的时候总是往后追加数据，读的时候才会综合这些写入片段，选择每列的最大版本号去返回。 LSM Trees还有一个属性是数据写入文件中就不可以更改（这些文件在Cassandra中叫做SSTables）。正如最初讨论的那样，显然对于这样一个系统，删除只能通过一种特殊的写来实现。读的时候根据墓碑的时间戳，忽略小于这个时间戳之前插入的数据。

从像apache cassandra这样的系统中，删除分布式主从复制的数据远比关系型数据库要复杂的多。当我们想到cassandra的数据是存在磁盘上的多个文件中，这个删除的过程变的超级有趣。在这样一个系统中，需要写入一个被称作墓碑(tombstone)的标记，用于记录一个删除操作，表示之前的值被删掉了。尽管你可能觉得这很不正常，或者难以理解(特别是当你意识到删除操作竟然是要占空间存储的），我们将用这篇博客，使用一些例子来解释这其中究竟发生了什么。 Cassandra：可用性和一致性的考虑 在我们深入细节之前，我们需要快速回顾一下Cassandra作为一个分布式系统是怎么工作的，特别是关于可用性和一致性。这对于我们等会解释分布式删除，以及一些潜在问题，非常有必要。 可用性：为了保证Cassandra可以复制数据，也就是说根据副本因子，存储的每一条数据都有多份拷贝。副本因子定义了每个keyspace（库的概念）在每个DC（数据中心）中的拷贝个数。通过配置，每个拷贝可以分布在不同的机架上，只要你有足够的机架，并且通过配置机架策略让系统考虑这些因素。有了这个，当任何一个节点(或者是一个机架，再说一遍，这个取决于你是否进行了配置)挂了，数据仍然可以通过其它副本进行读取。 一致性：为了确保读取数据的强一致性，我们必须遵循下面的原则： CL.READ = 读一致性. 从至少多个节点得到读响应，我们才承认它是一个成功的操作. CL.WRITE = 写一致性，同上. RF = 副本因子（个数） 要满足 CL.READ + CL.WRITE > RF，只有这样，我们才能保证至少有一个写入数据的节点被读到（译者注：好有道理） 通常的例子：我们考虑下面的设置： RF = 3 CL.READ = QUORUM = RF/2 + 1 = 2 CL.WRITE = QUORUM = RF/2 + 1 = 2 CL.READ + CL.WRITE > RF –> 4 > 3 这样的配置，就有很高的可用性，没有单点故障(SPOF),我们可以承担挂掉一个机器的风险，因为我们可以保证有一个写数据的节点可以读到，再加上最新者写入者胜出(LWW)算法（译者注：记录以写入时间戳最新的为准），就可以知道哪个节点的数据是正确的。 先把这种配置和做法记在脑子里，我们看一些执行删除的例子。

14、是不是单个seed意味着单点故障？ 即便没有seed节点，集群也可以运行和重启，但是不能再往集群里增加节点。还是推荐在生产系统中配置多个种子节点。 15、为什么不可以在jconsole里调用某个jmx方法呢？ 一些JMX操作的参数是个数组，而Jconsole并不支持数组型参数。对于那些不能用jconsole调用的操作（在jconsole里点击按钮无效）。有需要自己写一个JMX客户端去调用，或者使用一个支持数组的jmx监控工具。 16、为什么我会在日志文件里看到 “… messages dropped …“这样的信息？ 这是cassandra在面对超出自己处理能力的请求时，为了保护自己做出的流控措施。 一个节点接收到其它节点发送过来的消息，但是在他们合适的超时时间内不能得到处理（具体参考 read_request_timeout, write_request_timeout等配置项）。就会被丢弃，而不是处理（因为接受用户请求的节点也就是协调节点不会再等这个响应返回） 对于写，这意味着它的请求不会被写入所有的副本，这个一致性将会被读修复、hints或者是人工修复等方式修复。因为这，一个写操作返回给客户端的结果就是超时的。 对于读，意味着一个读请求可能没有完成。负载流控是cassandra架构的一部分，如果这个问题一直持续下去，这标志着你的节点或者集群已经超载了。 17、Cassandra因为java.lang.OutOfMemoryError: Map failed挂掉了 如果cassandra挂掉的时候输出“Map failed”的消息，表示操作系统不允许java锁定更多的内存。在linux里，内存锁定是有限制的，你可以通过/proc//limits确认，并提高它（比如适应ulimit命令）。还有vm.max_map_cout参数。注意debian安装包会自动为你调整这些参数。 18、如果再同一时刻发生两次更新会发生什么？ 更新顺序必须是可交换的，因为他们很有可能到达不同副本的顺序是不一样的。只要cassandra有一个确定的方法选出这个赢家（相同的时间戳），那么这在其它节点也是一样的，这是一个重要的实现细节。也就是说，对于相同时间戳的操作，Cassandra遵循以下两个原则：第一：删除要优先于更新和插入，第二：如果两个都是更新，那个在语法上比较大的更新会被选中。 19、为什么在加入一个新节点的时候，会有Stream failed错误？ 两个可能性： GC可能导致的长时间暂停可能会扰乱传输进程 在后台执行的压缩会导致传输时间太长从而TCP连接断开。 对于第一种情况，建议在应用中经常的进行GC优化， 第二种情况，你需要设置系统的TCP keepalive参数短一些（linux中默认是很长的），尝试执行下面的语句： sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5 如果要让这些配置永久有效，需要把他们加入到/etc/sysctl.conf文件中。 注意：GCE(Google的云服务吧)的防火墙经常切断TCP连接，当一个连接超过10分钟不活动的话。这种情况强烈推荐执行上述命令。

9 我可以通过批量提交加速我的大量写入吗？ 不，使用批量提交只会带来延迟尖峰，使用异步的INSERT来代替，或者使用真正的“批量载入” 对同一个分区key的批量更新是一个例外，只要一个批量的大小保持在合理范围内，还是有好处的，但是要记住不要任何时候都盲目使用批量。 10、在Red Hat企业版（RHEL）中，节点无法加入到集群中。 查看SELinux是否开启了，把它关掉。 11、我怎么取消订阅apache cassandra邮件列表 发邮件到user-unsubscribe@cassandra.apache.org 12、为什么使用top命令看到cassandra使用了比java虚拟机限制的对内存还要多的内存？ cassandra内部使用内存映射文件(mmap). 也就是锁，我们使用操作系统的虚拟内存系统把一定数量的磁盘文件映射到了cassandra进程的地址空间里。这将使用虚拟内存，也就是地址空间，这可以使用一些工具例如top命令发现，不过在64位操作系统中，虚拟地址空间是无限大的，所以你不需要担心这些。 那使用的内存的所代表的意义是什么呢？它是使用brc()或者mmap所实际占用的内存，问题的关键是，对于mmap的文件不一定会永久驻留在内存里。所以这些使用的内存不过是缓存而已，就像系统的IO会使用内核的page缓存一样。 一般的IO和mmap的差别就在于mmap引擎的内存是映射到某个进程上的，所以你用top命令可以看到该进程对应的虚拟内存大小。mmap比IO的一个好处是只要内存里有，你里面就能读到了，不会碰到page fault(读系统page缓存，内核可能需要做semi-context切换？)，更多细节参考http://www.varnish-cache.org/trac/wiki/ArchitectNotes 13、种子节点是什么？ 种子节点用于节点启动的时候发现整个集群。 如果你配置了你的节点指向几个节点作为种子，那么你集群中的节点会发送相比非种子节点较多的gossip信息到种子节点。换句话说：种子节点相当于gossip网络的集线器，每个节点通过种子节点可以很快知道其他节点的状态。 在一个节点新加入集群的时候，需要指定种子节点用于发现集群中其它节点，当你增加一个新节点到集群中的时候，你需要至少指定一个活着的种子节点可以连接，一旦一个节点加入这个集群，它学习到了其它节点，他在下次启动的时候就不需要种子节点了。 你可以任何时候设置任何一个节点为种子， 对于种子节点没有什么特殊的，只要你把它写入种子列表里，他就是一个种子节点。 种子是无法自启动的(bootstrap)(因为如果一个节点把自己加入了种子列表，那就是说他需要自己传输数据给自己)，如果你需要这样，你可以先把这个节点当非种子节点启动，等启动以后再把它加入种子列表里。当然如果你是初始化一个新集群，没有任何数据，那你就不需要担心这个事情了。 提醒以下两点： 为每个Data center都选择大于两个节点作为种子节点 保持你所有节点种子列表是一样的。

1、为什么不可以设置listen_address为0.0.0.0（意思是监听所有地址）？ Cassandra是一个基于gossip协议的分布式系统，监听地址是用来告诉其它节点来访问的，告诉别的节点说“连接我任何地址都可以”，是一个糟糕的想法，如果集群中不同的节点使用了不同方式的地址，悲剧的事情就要发生了。 如果你不想为你集群中的每个节点单独配置ip（非常可以理解）,你可以不配，空着它，Cassandra将会使用InetAddress.getLocalHost()来选择地址，然后只要你或者你的运维团队保证这个是正确的(/etc/hosts/,dns 等等要配置对)。 一个例外是JMX,他默认监听的地址是0.0.0.0（这个是java的bug 6425769） 请看CASSANDRA-256 和 CASSANDRA-43获取这方面更多的细节。 2、cassandra用了哪些端口？ 默认Cassandra使用7000作为集群通信端口（如果开启了SSL就是7001端口）。9042端口用于native协议的客户端连接。7199端口用于JMX，9160端口用于废弃的Thrift接口。内部节点通信以及native协议的端口在cassandra配置文件里可以配置。JMX端口可以在cassandra-env.sh配置（通过JVM的参数)。所有端口都是TCP的。 3、当往集群中增加新节点的时候，对于存在的数据发生了什么？ 当一个新节点加入到集群，它将会自动连接集群中的其它节点，并且去复制正确的数据到本地，同样的增加、替换、移动、删除节点都是这样的。 4、我删除了数据，但是磁盘使用率没有变化，这是为什么？ 写入到cassandra里的数据会被持久化到SSTable文件里，SSTable文件是不可改变的，也就是说当你执行删除的时候，数据不会从文件中被去除掉的。相反，一个标记（也叫tombstone)会被写入用于标记对应记录的新状态。不用担心，当数据和tombstone发生第一次compaction的时候，数据会被删除掉，相应的磁盘空间也被回收，你可以了解关于Compaction的更多细节。 5、为什么用nodetool ring只能看到一条记录？ 即便所有节点输出的日志里可以看出，他们都发现彼此加入到了这个ring。 这个发生于你的所有节点都配了通用的token，不要这么做。 这经常发生于哪些使用VM部署cassandra的用户，（特别是使用Debian package，它会在安装完自动启动cassandra，所以会生成token并保存它。），安装好后就把VM整个克隆出另外的节点。 增很容易修复，只要把数据目录以及commitlog目录删除，然后保证每个节点是随机生成的token，再启动就可以了。 6、我可以修改一个正在运行中的集群中的keyspace的副本因子吗？ 可以，但是修改后需要执行repair或者cleanup来改变已存数据的副本个数。 首先使用cqlsh修改目标keyspace的副本因子。 如果你是减少副本因子，你可以执行nodetool cleanup去删除多余的副本数据，对每个节点都要执行。 如果你是增加副本因子，你需要执行nodetool repair来保证数据的副本个数满足当前的配置。 Repair只要对每个副本集执行一次即可。这是个敏感的操作，这会影响集群的性能。强烈建议执行rolling repair，因为试图一次修复整个集群的话，那可能是个坑。 7 可以使用cassandra存储大的二进制字段吗？ Cassandra并没有对存储大文件或者二进制，以及这样一个二进制数据被经常读，也就是整个发送到客户端的情况进行优化。因为存储小的二进制数据（小于1MB)应该不是问题。但是还是建议把大的二进制数据分隔成小块。 需要特别注意的是，任何大于16MB的值，将被Cassandra拒绝掉，这是由max_mutation_size_in_kb配置项决定的（这个配置项默认是commitlog_segment_size_in_mb的一半，commitlog_segment_size_in_mb默认是32M)。 8、Nodetool连接远程服务器的时候，提示“Connection refused to host: 127.0.1.1” ，这是为什么？ nodetool依赖JMX，JMX依赖RMI。RMI在两端通信的时候会根据需要创建自己的listenners和connectors。通常，这些都是底层透明的，但是不正确的hostname解析，无论是在连接方还是被连接方，都会导致错乱和这样的拒绝异常。 如果你在使用DNS。确保两端机器的/etc/hosts文件是正确的。如果还是失败的，你可以尝试通过jvm选项-Djava.rmi.server.hostname=指定你要连接的远程机器名称给JMX接口，配置项大体在cassandra-env.sh文件的靠下的位置。

余承东官方微博： 表示9月1日IFA2016电子展期间，有新机要发布，发布会的时间为北京时间9月1日16点30分。 然而，一直没有透露具体手机型号的信息。随着华为手机产品线总裁何刚否认新品是华为Mate 9/S系列之后，全新系列Nova的消息也越来越多，预计将在发布会上再进行推出。不过，近日来余承东又再一次主动爆料，暗示发布会上新品不止一款。 在微博中，余承东连续晒出了多张海报图，而每次都会有两款手机现身，摄像头部分可以明显看出不同，并且四张海报都不一样！

7月11日，荣耀年度旗舰新品荣耀8，在上海东方体育中心盛大发布。在拥有旗舰性能的同时，荣耀8在外观ID设计上大胆创新，以全新设计理念和制造工艺，诠释出“美得与众不同”的产品主张。今年人气超女王金金出席现场，并激情献唱高晓松专为荣耀所做的主题曲《荣耀》，引发现场合唱，将气氛推至高潮。 在一体化的设计理念下，荣耀8不仅延续了荣耀年度旗舰的极致科技、领先配置和强劲性能，更融入了荣耀对潮流的理解，并革命性地赋予其极致美学。 作为荣耀首款采用双面2.5D玻璃设计的机型，荣耀8在颜值、手感、拍照、续航、性能方面全面进化 : 为了追求更高的颜值，除采用亮屏0.4mm超窄可视边框和全新镜面屏幕边框设计外，荣耀8更带来工艺的突破，通过15层工艺技术，打造出蕴繁于简的视觉美学。荣耀8的背部玻璃后壳油墨丝印层、多层光学镀膜、3D光刻层、光栅纹理载体层、AR光学增透层、2.5D第三代大猩猩玻璃和AF指纹易擦拭涂层等15层工艺匠心打造，创新性的技术，更高的工艺，最终为消费者带来了炫美的极光效果;而5.2英寸LTPS屏幕的运用，对称美学理念，完美均衡了屏幕的观感和整机手感。 配置方面，一体化纯平设计的黑白+彩色双1200万像素平行镜头;配备16纳米的麒麟950芯片和4GB四通道内存超强组合，以及内置的i5智能协处理器，对手机内的传感器进行精准高效的管理，同时可有效降低整机功耗;4G+网络、VoLTE高清通话，以及智能手机行业首次运用的WLAN+3.0技术，带来更任性的网络体验;3000mAh高密度电池配合领先快充技术，同时支持新一代智电技术;在UI方面，搭载基于Android 6.0操作系统的EMUI 4.1。 此外，荣耀8还拥有多项黑科技，如智灵与指纹二合一的多功能指纹键、国家眼科工程中心技术指导的护眼模式、安全便捷的移动支付功能，以及引领智控再次革新的智能4.0红外遥控技术等，全面进化带来更优秀的用户体验。 全新荣耀年度旗舰荣耀8包括4个版本，满足消费者的不同需求。其中，4G+64G全网通版售价2499元，4G+32G全网通版售价2299元，3G+32G全网通版售价1999元，3G+32G运营版售价1999元。在备受年轻消费者关注的颜色方面，荣耀8有流光金、幻夜黑、珠光白、魅海蓝、樱语粉共5种颜色，结合独特背部玻璃极光，带给消费者差异化的炫酷潮流体验。 同时，此次发布会除发布荣耀8这款“美得与众不同”的全新旗舰产品外，还发布了另外一款“与众不同”的产品——荣耀畅玩手环A1 SS版，并将在天猫旗舰店和华为商城于7月11日到18日预售， 在7月19日正式开售。 除发布全新旗舰产品外，此次发布会的一大亮点是，正式宣布吴亦凡成为荣耀品牌中国区代言人。吴亦凡是当下最具影响力的潮流偶像，在成为娱乐圈票房保证的同时，更以自己在体育、时尚等领域的超凡表现，成为最受年轻人喜爱的、时下炙手可热的多栖明星。选择吴亦凡代言，是荣耀与年轻消费者互动的重要营销举措，也是荣耀8“美得与众不同”产品主张的最佳呈现。此外，荣耀8的国际化形象和全球化的销售预期与吴亦凡的全球化形象高度重合。毫无疑问的是，吴亦凡的助阵将让本就惊艳的荣耀8如虎添翼，让科技美学旗舰开启一股青春风暴。

JNI的目的是可以使用C/C++完成部分逻辑，一方面 代码复用，避免重复劳动。另外一方面有些东西还是C语言处理起来比较方便,比如和底层驱动程序打交道等等。JAVA调用C/C++方法，就要把参数传递给C/C++代码，或者C/C++代码可以获取到JVM的内存数据, JAVA和C之间可以数据交互。 1、数据类型 JAVA和C/C++之间传递数据，就要有相互对应的数据类型。 首先是基本类型，每种语言都会有的，所以直接用typedef 定义完成： typedef unsigned char jboolean; typedef unsigned short jchar; typedef short jshort; typedef float jfloat; typedef double jdouble; typedef long jint; typedef __int64 jlong; typedef signed char jbyte; 在java里除此之外的对象都是继承于java.lang.Object。所以JNI里也定义了一个jobject的结构体。 这样java所有的对象都可以用jobject传递。 参考官方文档：http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/types.html 为了方便使用，JNI还定义了一些特殊的常用对象，比如类对象jclass, 异常对象jthrowable，数组对象jarray等等。 不过这些对象都是空的，也就是你不通过调用它们的方法的方式去调用java里的方法。 如果想调用它们的方法，或者获取它们的一些属性。你需要把它们当作参数，传递给JNIENV的对应api。 比如你想获取一个数组的长度，你需要调用JNIENV的GetArrayLength方法： jsize GetArrayLength(jarray array) 2、JNIEnv指针。 在JNI自动生成的代码里，函数参数，必须有一个JNIEnv *指针，这个就是用来调用JVM的方法的。 关于JNIENV的定义可以查看jni.h。你会发现它是一个struct。 如果你是C++语言实现，那么它这个struct就相当于一个class，大家知道在C++里，struct和class是没有多大区别的，唯一的区别就默认访问权限的问题。这都不是很重要。重要的是struct里可以定义方法和属性。JNIENV里提供了一系列的api，供使用者调用。 如果是C语言实现的呢，会发现JNIENV也是一个struct，但是C语言是一种面向过程的语言，他没有对象的概念，它的struct里是不能定义方法的。但是有一个叫“函数指针”的东西，可以让C语言实现一种面向对象的感觉，JNI就是这样做到的，它在struct里定义了一系列的函数指针，用于访问JVM。 这样无论C，还是C++。都可以使用JNIENV的api访问jvm。 jni.h里是通过__cplusplus控制的 都有那些方法，可以查看oracle官方文档： http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html 3、共享内存。 Java除了提供参数传递的方式，和C/C++交互数据之外，还有一种共享数据的方式就是共享内存。Java里可以直接申请JVM的堆外的内存，和C语言共用。 那就是java里的一个特殊类：ByteBuffer，它的allocateDirect方法，可以直接在JVM之外的内存中开辟空间。 这种开辟内存的方式要比直接申请JVM堆内内存耗时多，所以这种方式一般用于使用比较频繁，可以重复使用的场景。 比如java和c之间有大量数据要交互，那么就可以使用ByteBuffer申请一块一定大小内存作为缓存。使用ByteBuffer可以大量减少JVM和C语言之间的内存copy产生的开销 下一篇学习ByteBuffer的实际使用。

一个maven的典型目录结构: src/main/java src/main/resources src/test/java src/test/resources 根据含义src代码源码库， main代表主代码 test表示测试代码。java表示java部分。 那么如果再加上C语言部分，那目录可以这样安排 src/main/java src/main/c — c语言部分 src/test/java src/test/c — c语言测试代码 src/test/resources include —引用的其它c语言头文件 lib —引用的其它动态链接库 使用maven编译c语言，还是要用插件： org.fusesource.hawtjni maven-hawtjni-plugin 1.13 这个插件会帮你生成一个c语言工程（主要是configure文件和makefile文件），并帮你编译成so文件，并放到jar包的指定目录下，非常好用。 示例配置如下： org.fusesource.hawtjni maven-hawtjni-plugin 1.10 build-linux64 ${project.artifactId} ${project.build.directory}/linux64 ${basedir}/src/main/c ${basedir}/target/classes/ --with-arch=x86_64 CFLAGS=-I${basedir}/include LDFLAGS=-L${basedir}/lib LIBS=-lXXXX linux64 true true generate build compile configureArgs 里包含了makefile需要的参数，其中XXXX表示你依赖的库名，也可以加上更多你需要的其它的参数。 假设你的工程名叫hello。执行mvn clean package 之后 maven会帮你在你的target/native-build目录下生成一个c语言工程，并执行相应操作系统的编译。 就比如上面的linux64位系统，最终会生成一个libhello.so文件到你的jar包的META-INF/native/linux64/ 目录下 你可以用各种手段使用System.loadLibrary加载它。 下一篇学习java和c语言之间的参数传递和方法调用。

程序都是从hello world开始的，写一个简单的demo，java里调用c语言的方法输出一句hello world。 第一：首先实现一个java类：com.zhaoyanblog.Demo package com.zhaoyanblog; public class Demo { static{ System.loadLibrary("demo"); } public static void main(String[] args) { Demo demo = new Demo(); demo.printHelloWord(); } public native void printHelloWord(); } 声明为native的方法，jvm会主动从加载的library中对应寻找。 System.loadLibrary就是用于加载c语言编译的库文件。 在linux下面lib库文件的命名默认是： lib+{name}+.so java会到环境变量java.library.path对应的目录下寻找并加载。 第二: 编写c/c++语言部分 使用javah得到c/c++对应的头文件, 在com目录的父目录下执行 javah -jni javah -jni com.zhaoyanblog.Demo 会产生一个头文件 com_zhaoyanblog_Demo.h /* DO NOT EDIT THIS FILE - it is machine generated */ #include /* Header for class com_zhaoyanblog_Demo */ #ifndef _Included_com_zhaoyanblog_Demo #define _Included_com_zhaoyanblog_Demo #ifdef __cplusplus extern "C" { #endif /* * Class: com_zhaoyanblog_Demo * Method: printHelloWord * Signature: ()V */ JNIEXPORT void JNICALL Java_com_zhaoyanblog_Demo_printHelloWord (JNIEnv *, jobject); #ifdef __cplusplus } #endif #endif 根据头文件完成源文件com_zhaoyanblog_Demo.cc ...

Cassandra使用一个类似于日志结构的结合树（Log-Structured Merge Tree）的存储结构，不像传统关系数据库那样使用B-Tree。 Cassandra会避免在写之前去读。 “写前读”（Read-before-write）， 特别是在一个大的分布式系统里，会对读性能产生影响，还会带来其它问题，比如，两个客户端同时去读，其中一个去更新该行的A列，另外一个去更新该行的B列，就可能把对A列的更新覆盖掉。“写前读”，也会破坏cache，增加IO。 为了避免“写前读”的情况，cassandra的存储引擎会对即将要进行的插入、更新进行整理，只会按顺序，以追加的模式仅写入这一行更新的部分。 。 一个日志模式的存储引擎，为了避免数据相互覆盖，使用顺序IO去更新数据写入普通硬盘HDD或者固态硬盘SSD是必须的。 在HDD中，随机写比顺序写会导致大量的寻址操作，这个寻址操作的危害是相当大的。使用顺序IO，从而避免更多写入被放大和磁盘故障，Cassandra特别适合廉价的、大众消费的SSD。

Cassandra的写操作包含几个过程。从开始实时写日志到最后进行压缩。 1、把数据写入commit log 2、数据写入内存表memtable 3、从memtable中刷新 4、存储到磁盘中的sstables里 5、压缩 写日志和memtable存储 当有一个写入发生，cassandra会把数据存到内存里叫memtable的数据结构里，也会写到磁盘的commitlog里，提供持久化存储。commitlog接受每个请求，并且持久化保存，甚至是断电。memtable是一种回写cache，cassandra通过key可以在memtbale里查询数据。memtable的大小是有限制的，当到达一个限制就会被刷新。 从memtable刷新数据。 当memtable的内存超过了配置的阈值，memtable里的数据包括索引，就会进入一个刷新到磁盘的队列里。你可以通过修改cassandra.yaml里的 memtable_heap_space_in_mb配置项来控制这个队列的大小。当要刷新的数据超过了队列大小，cassandra就会阻止写入直到下一个刷新成功。你可以使用nodetool flush 手动触发一个刷新，通常在重启节点之前，建议刷新一次memtable，这样可以减少重放commitlog的时间。为了刷新数据cassandra会吧memetables根据token排序，然后顺序写到磁盘上。 磁盘上数据存储到sstables中 对于在commitlog里的数据，当在memtable里的对应的数据被刷新到一个sstable中之后会被清除。 Memtables和SStables都是分表存储的，SStables是不可以改变的，当从memtbale中刷新到磁盘上后就不会再写入。因此一个分区可以通常会保存到多个sstable文件中。对于每个sstable，cassandra会创建如下结构化数据： 1、分区key索引：一个分区key的列表和对应的在data文件中的起始位置。 2、分区key汇总（在内存里）：一个分区key索引的抽样 3、布隆过滤器 压缩 周期性的压缩是cassandra作为一个健康数据库所必须的，因为cassandra不会把数据插入或者更新到具体的位置。当插入或者更新发生了，并不会去覆盖原来的数据，而是重新写入一个新的时间戳版本的数据到另外一个sstable中。cassandra管理在磁盘上不断累积的sstable，就是使用压缩。 cassandra也不会去实际删除数据，因为sstable是不可以修改的。而是用墓碑的方式标记数据被删除了，墓碑存在一个可配置的周期，是表的一个参数 gc_grace_seconds。 在压缩的过程中，会有一个磁盘使用空间以及IO的临时飙升，因为老的和新的sstable会并存，这个图描述了压缩的过程： 压缩会根据分区key合并多个sstable中的数据，选择具有最新时间戳的进行存储。Cassandra可以高性能的合并数据，而不会产生随机IO，因为在sstable里的row都是根据分区key排序存储的。在删除了墓碑和要删除的数据，列和行数据后，压缩的过程会把这些sstable压缩成一个文件。老的sstable文件会在堆积到该文件上的查询请求结束后尽快的删除。这样老的sstable占用的磁盘空间又可以重复使用了。 cassandra2.1改进了压缩后的读性能，通过一种增量式的替换压缩过的sstables。而不是等到整个压缩完才去删除老的sstable。cassandra可以直接从新的sstable中读取，甚至在它完成写入之前。 当数据写到新的sstable，读请求就会访问新的sstable，在老的sstable中相应的数据不会再被访问，并且从系统的page cache中剔除掉。因此当缓存新的sstable的增量过程开始的时候，读取就不会从老的读，相应的cache也会消失。因此可以预见cassandra提供了一种高的性能甚至是在高负载下。 原文地址：https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_write_path_c.html