nacos配置

机器基本配置选择

Cassandra的性能使用可以随着机器的硬件配置，以及集群的节点数的横向和纵向的升级而相应的有所提升。

CPU

Cassandra内部会有很多地方使用多线程进行处理，一般配置里面对于读写而言，写操作是CPU bound，所以如果系统的写操作会相对多一点，对cpu的要求也会相对配置要好一点，一般至少是2c起步，如果是生产环境对写要求更高，相对的cpu核数应该更好。

内存

Cassandra使用java 语言编写，会用到jvm-on heap内存以及offheap内存，其中jvm预先想操作系统申请的内存大小是系统大小的1/2, 其中off-heap会使用于压缩元数据，bloom filter等等。官方建议生产环境内存不低于8G，但是具体可以视自己的需求再说，对于gc算法来说：

• 堆内存小于12G，推荐cms算法；

• 大于12G堆内存的话，可以使用G1 算法；

磁盘

对于cassandra而言有几个地方需要使用到磁盘，commitlog、hint、cache-file、sstable-file。其中对我们来说，我们需要重点关注commitlog的文件以及sstable的文件，因为写操作会先写commitlog，然后把数据丢到memtable，然后memtable会异步的dump到磁盘成为sstable的文件，而且sstable后台会进行异步的compaction操作合并成新文件。那么这里commitlog的会影响我们的写性能，常见的建议是commitlog的配置

磁盘与放置sstable的data 目录分开配置，commitlog单独配置一块盘，因为写commitlog的速度直接影响写操作的速度，所以建议commitlog的配置磁盘需要稍微好一点，但是容量不需要很大，因为commitlog的数据在相关memtable数据dump到磁盘以后就会删除。只有存留在memtable的数据在commitlog里面以做节点crash以后做replay使用。

存放sstable的磁盘可以使用HDD/SSD磁盘，相关cassandra有优化配置，那么这里的话可以使用多块磁盘组合使用Raid0或者cassandra所谓的JBOD方式，使用其他的Raid1-Raid5不是最优的使用推荐，因为在节点层面有多数据副本冗余。具体磁盘容量视集群业务需求以及其他配置来定。

节点数

Cassandra可以是单节点（需要设置replicat factor 为1），2个节点（replicat factor最多是2），3个节点，…..个节点，理论上的扩容是线性的，无上限的扩容，可以从1 到很大。但是常见一般300个物理节点基本是可以了。

设计表从查询的结果开始设计表（结果表）。

• 存储空间设计

Cassandra每个表都是存储在磁盘上的单独文件中，相关的列尽量保持在同一个表中（磁盘文件）。

搜索单个分区的查询性能最佳，优化最小搜索分区数量。

• 排序设计

Cassandra查询中的ORDER BY仅支持聚类列（Clustering columns）排序。

• 分区单元值计算方法

避免分区太宽，分区中的单元值太大。

分区中的单元值计算方法：

分区中的单元值=静态列数+表的行数*（列数-主键列数-静态列数）

Cassandra的限制是每个分区20亿。

硬件选择

与大多数数据库一样，Cassandra吞吐量随着更多的CPU内核，更多的RAM和更快的磁盘而提高。虽然Cassandra可以在测试或开发环境（包括Raspberry Pis）的小型服务器上运行，但最小生产服务器至少需要2个内核和至少8GB的RAM。典型的生产服务器有8个或更多的内核和至少32GB的RAM。

中央处理器（CPU）

Cassandra高度并发，使用在尽可能多的CPU核上运行的多线程来处理许多同时请求（读和写）。Cassandra写入路径需要被优化（写入提交日志，然后将数据插入到memtable中），因此写入严重受CPU约束。所以添加额外的CPU内核通常会提高读取和写入的吞吐量。

内存（Memory）

Cassandra在Java VM中运行，这将预分配固定大小的堆（java的Xmx系统参数）。除了堆之外，Cassandra还将使用大量的RAM非堆用于压缩元数据，bloom过滤器，行，键和计数器缓存，以及进程内页面缓存。最后，Cassandra将利用操作系统的页面缓存，将最近访问的部分文件存储在RAM中以便快速重用。

为了获得最佳性能，运营商应根据其各自的工作负载对其集群进行基准和调优。但是，基本准则建议：

• 应该总是使用ECC RAM，因为Cassandra几乎没有内部保护措施来防止位级别损坏

• Cassandra堆应该不小于2GB，并且不超过系统RAM的50％

• 堆大小小于12GB应该考虑ParNew / ConcurrentMarkSweep垃圾收集

• 堆大于12GB应考虑G1GC

磁盘（Disks）

Cassandra将数据保存到磁盘中，用于两种非常不同的目的。第一个是在进行新写入时的commitlog，以便在崩溃或系统关闭后可以重播。第二个是在超过阈值时到数据目录中将memtables作为SSTables刷新到磁盘。

委托日志接收对Cassandra节点的每个写入有可能阻塞客户端操作，但它们只能在节点启动时读取。另一方面，SSTable（数据文件）写入异步发生，但是满足客户端查找的读取需要。SSTables还在称为压缩的过程中定期合并和重写。commitlog目录中保存的数据是尚未永久保存到SSTable数据目录的数据 - 一旦将其刷新到SSTable数据文件，它将被定期清除。

Cassandra在旋转硬盘和固态磁盘上表现非常出色。在这两种情况下，Cassandra中排序不变的SSTables允许线性读取，只需要很少的查找和少量的覆盖，通过避免写入放大，最大化HDD的吞吐量和SSD的寿命。但是使用旋转磁盘时，重要的是commitlog（commitlog_directory）位于一个物理磁盘（不仅仅是分区，而是物理磁盘）上，而数据文件（data_file_directories）也应设置为单独的物理磁盘。通过将提交日志与数据目录分离，写入可以附加到提交日志之后从中获益，无需在读取磁盘上各种SSTables的请求数据时查找盘片。

在大多数情况下，Cassandra旨在通过多个独立，廉价的服务器提供冗余。因此，对数据目录使用NFS或SAN是反模式的服务器通常应避免使用。类似地，使用RAID0或JBOD而不是RAID1或RAID5,因为通常更好地服务器具有多个磁盘 。Cassandra提供的复制消除了在磁盘层进行复制的需要，因此通常建议运营商利用RAID0的额外吞吐量，而不是使用RAID1或RAID5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000保护故障。

常见的云选择

Cassandra的许多大型用户在各种云中运行，包括AWS，Azure和GCE - Cassandra将很乐意在这些环境中运行。用户应该选择与物理空间所需的类似的硬件。 在EC2中，常用的选项包括：

• m1.xlarge实例，它提供1.6TB的本地临时旋转存储和足够的RAM来运行中等工作负载

• i2实例，其提供高RAM：CPU比率和本地短暂SSD

• m4.2xlarge / c4.4xlarge实例，提供现代化的CPU，增强的网络和与EBS GP2（SSD）存储

m4.2xlarge / c4.4xlarge实例，提供现代化的CPU，增强的网络和与EBS GP2（SSD）存储