性能 / (开发效率+复杂度)

首先RocksDB不是分布式数据库，只是个单机的存储引擎然后很多分布式数据库拿来用。

在不开源的各大公司自己造的轮子中，C++应该一直是主流，无所谓是否上升吧。

而开源的话，我觉得是在上升，虽然我是搞Java的……架构上完全抄Cassandra单纯靠各种优化的ScyllaDB、号称介于OLAP和OLTP之间的kudu，都是C++的。

HBase那个年代，可以算是刚有分布式数据库，那个时候只要出的早、能用，加上一些商业因素，就容易火。单机到分布式是质变，大家要求不高。但随着分布式数据库这些年没什么新的架构/设计出现，顶多有个raft。总体来说就那么几种大的设计，大家就开始对现有的架构进行优化了。而优化很大程度上是优化性能，优化性能基本上只要你不用C++都还是有瓶颈…尤其是Java还有GC…（就算你用新的架构，raft来写，如果接着用Java也还是没显著优势）这和C++现在的开发效率关系不大，或者说即使没有C++11，这些数据库大概率还是会用C++写。

另外还有个问题是，以前其实系统的瓶颈在IO，但是现在有了ssd甚至pcie-ssd，还有了万兆网卡，CPU重新成了瓶颈之后，C++的优势就更明显了。

如果不限定开源系统的话，C/C++从来就是绝对的主流。无论是谷歌的几件套，微软的的scope和Azure，亚麻的很多系统，VMware等其他巨头，都是C/C++为主。

开源的几件套也不乏C/C++的流行项目，从Redis/memcached，到MongoDB，MySQL cluster。其实Java倒是大都仅限于Hadoop生态系统，以及Casandra。很多时候看，是一个偶然情况还是必然趋势其实还真不好说。

另外C/C++开发门槛的降低，我认为更重要的因素并不是新语言特性，而是代码扫描及验证工具的出现和成熟。当然C++11的智能指针也是减少内存泄漏的因素。

十年前，还在使用千兆网卡和Sata硬盘的时代，分布式存储只要软件写得尚可，没有太多锁的开销，性能瓶颈要么在磁盘IO要么在网络IO。

但是时代在变。

存储介质和存储协议方面，有了大容量的内存、PCIe SSD、NVMe PCIe SSD、SPDK等；网络方面，有了万兆网卡和infniband等。这些使得存储的性能瓶颈向存储软件层转移，也对存储软件在内存使用、线程模型方面有了更高的要求。

相对于那些有虚拟机的语言，C++语言在内存模型和线程模型方面更可控，便于开发人员对每个细节精雕细琢，使软件层对IO的影响降到最低。

如题主所说，C++11/14/17中对C++的改进，提升了C++的开发效率，但我认为它不是必然因素，C++98也一样能写出出色的代码。

时势造英雄，是这个时代需要C++，所以它站在了舞台的中央。

很多人一直在宣称 “语言不重要，重要的是思想”，“CPU很快”，“瓶颈都在IO”，“瓶颈都在网络”……

实际上，这些 “高屋建瓴” 的论点从来都是谬论，最近几年，CPU 的发展放缓，SSD 和 万兆网依然持续高速发展，这些谬论的荒谬之处也体现得越来越感人……

实际上，C++很好，至少是“足够好”，语言功能丰富，性能卓越，唯二的问题在于：

1. C++ 太复杂了，学习成本太高
2. 人，使用 C++ 的人，水平参差不齐，水平高的喜欢炫技，水平差的得过且过

所以，使用 C++ 需要用心学习，同时需要高度自律，不要炫技！

很多人提到了 hadoop，说实话，如果 hadoop 是大家自律地使用 C++ 开发的，分布式领域应该是另外一番景象……

趋势要动态的看：

• 缺乏高性能的nvme-ssd和rdma网卡的时候，x86的core足够，瓶颈在device-io，使用jvm多损耗cpu不是大事，但能降低技术门槛提高开发效率，有很大优势。现在单个io device速度提升了一个数量级以上rdma的以太网单卡能做到10G/s以上，nvme-ssd的带宽能到几个GB/s和million以上的4k 随机io。cpu的随机访问物理内存速度跟io device差不离了，瓶颈是memory wall了。如果还是用jvm的话，buffer的memory copy本身的cpu 开销和线程调度导致的cpu cache 污染就是很大的问题了。没有dpdk/spdk这种支持share nothing/ run-to-complete的micro controller framwork，根本无法发挥硬件的特性；所以说sylladb比cassandra快10倍的性能就出来了。redpanda相对于kafka而言也是又很大优势的。
• 通用cpu在单个die上scale多个core的做法，早期对jvm是很友好的，jvm的runtime对于多线程的封装和jdk提供的concurrency container，对于应用开发是非常nice的。但是后来单个die上scale多个core已经到了极限，只能走多个die的numa方式做scale。这种情况下单个server的物理core能够达到上百个。想要保持software随硬件资源的同步扩展，应用自己做计算调度就很重要，协程大火，带gc的golang相对jvm来说，吸引了更多项目。当然golang相对c/cpp来说也有自己的问题，比如gmp这种rumtime模型很难做rtc（rtc最好是框架来做，比如seastar spdk等，而不是编程语言的runtime），编译器比gcc还是弱。
• 通用cpu本身的算力不够。olap领域要做vectorize execution以提高并行度。向量引擎也并不是java搞不了，presto就做的不错，但是要真正发挥底层cpu的simd能力，jvm的auto vectorize的能力就很是不足了，ck这种手撸simd汇编的做法已经蔚然成风，databricks的spark的收费版本向量引擎也抛弃了jvm。presto的最大用户，meta的同学，最终整个新的c++项目velox。
• 码农的人力成本不再是瓶颈了，电费现在很贵，大家觉得通用cpu的图灵税太高，功耗高速度还慢。分布式存储和基础架构领域，有很多重复性高算力的计算场景，比如简单的压缩、加密、hash、包处理，统统dsa化，纠删码这种也不是不能dsa，或者说稍微复杂的就用fpga吧，连cpu都不要了，类似现在dpu在做的事情。都dsa了，c/cpp也要靠边站了。
• 上述趋势中，更本质驱动因素，是来自于半导体工艺的变化：摩尔定律马上要达到极限了，通过半导体制程降本增效已经快走不通了。未来想要降本增效，要么通过付出更多的开发代价，以提高软件的执行效率，或者硬件革命（dsa化）。
• 诚然jvm是一个伟大的生态，hadoop spark kafka之类非常出色的项目，然而未来的基础架构领域，c/cpp，rust/golang 显然会比jvm系语言空间要大很多。拼性能就是c/cpp/rust，拼开发效率的就用golang。jvm太强大了，以至于忽略了上述的新趋势，而且本身设计legacy太多，太复杂，适应新的趋势要付出的代价也太高了。