kafka数据存储及安全性简介(十三)

在kafka配置中最重要的生产者配置是：
acks
compression
batch size
而消费者最重要的配置是fetch size。如一个生产者的配置：

# ZooKeeper
  zookeeper.connect=[list of ZooKeeper servers]

  # Log configuration
  num.partitions=8
  default.replication.factor=3
  log.dir=[List of directories. Kafka should have its own dedicated disk(s) or SSD(s).]

  # Other configurations
  broker.id=[An integer. Start with 0 and increment by 1 for each new broker.]
  listeners=[list of listeners]
  auto.create.topics.enable=false
  min.insync.replicas=2
  queued.max.requests=[number of concurrent requests]

   kafka总是立即将所有的数据写入到文件系统，并且还可以控制flush策略在何时将OS缓存中的数据强制移出同时通过flush写入到磁盘上，flush机制可以控制数据在写入一段时间或者一定数量的消息后写入到磁盘上。kafka将会通过fsync来了解数据是否已经被flush到磁盘。如果是从一个已崩溃的kafka恢复过来的时候，使用fsync是无法了解到是否已经flush完整的，这个时候就需要kafka检查每个消息的CRC是否完整，并且重新构建偏移量文件作为恢复进程的一部分。需要注意的是在kafka持久化中并不需要同步数据到磁盘中，因为一个失败的节点数据可以从它的复制节点中进行恢复，因此持久化数据一般都是异步进行的。
    一般情况下我们使用默认的flush设置而禁用fsync就可以了，也就是说默认情况下是通过OS自己提供的flush机制及kafka的后台flush机制就可以了。我们通常认为复制提供的保证比同步到本地磁盘强，但是偏执的人仍然希望同时拥有这两个功能，因此应用程序级的fsync策略仍然受到支持。应用程序级别的flush设置有较低效率的磁盘使用模式，并且它会带来延迟，因为在大多数Linux文件系统中，fsync会阻塞对文件的写入，因而后台刷新执行更细粒度的页面级锁定。
在存储文件的选择上，kafka采用的是普通文件，并不依赖于具体的文件系统，但是最常用的文件格式还是EXT4和XFS，这2个文件格式都是Linux系统常用的文件格式，在过去EXT4有更多的用途，但是最近对XFS文件系统的改进表明，它对Kafka的工作负载有更好的性能特征，而且在稳定性方面更加友好。如果文件系统选择的是XFS格式，因为XFS文件系统有大量的自动调优功能，因此在创建文件系统或挂载文件系统时，它不需要对默认设置进行任何更改，需要改动的只有下面这2个方面：
    1.largeio：这将影响stat调用报告的首选I/O大小。虽然这可以在更大的磁盘写操作中获得更高的性能，但实际上它对性能的影响很小，甚至没有影响。
    2.nobarrier：对于具有电池支持的缓存的底层设备，此选项可以通过禁用周期性的写刷新来提高性能。但是，如果底层设备表现良好，它将向文件系统报告它不需要刷新，这个选项将没有效果。
    如果文件系统选择EXT4格式，因为EXT4也是Kafka数据目录的文件系统的一个可用选择，但是要想获得最大的性能就需要调整几个挂载选项。此外，这些选项在故障场景中通常不安全，并将导致更多的数据丢失和损坏，这些选项分别如下：
    1.data=writeback：Ext4默认为data=ordered，对某些写操作执行强顺序。Kafka不需要这种排序，因为它会对所有未刷新的日志进行非常偏执的数据恢复。这个设置消除了排序约束，似乎可以显著减少延迟。
    2.Disabling journaling：日志记录是一种权衡:它使服务器崩溃后的重新引导更快，但它引入了大量额外的锁定，增加了写性能的差异。那些不关心重启时间并希望减少写延迟峰值的主要来源的人可以完全关闭日志记录。
    3.commit=num_secs：这调整了ext4提交到其元数据日志的频率。将此值设置为较低的值可以减少崩溃期间未刷新数据的丢失。将此值设置为更高的值将提高吞吐量。
    4.nobh：当使用data=writeback模式时，此设置控制额外的排序保证。这在Kafka中应该是安全的，因为我们不依赖于写顺序，可以提高吞吐量和延迟。
    5.delalloc：延迟分配意味着文件系统在物理写发生之前避免分配任何块。这允许ext4分配较大的区段而不是较小的页，并有助于确保按顺序写入数据。这个特性对吞吐量很有好处。它似乎确实涉及到文件系统中的一些锁定，这增加了一些延迟变化。
    对于kafka中数据信息的监控，Kafka使用Yammer度量在服务器中报告度量。Java客户端使用Kafka度量，一个内置的度量注册表，最大限度地减少对客户端应用程序的传递依赖。两者都通过JMX公开指标，并可以使用可插入的stats reporter来配置为报告统计数据，以连接到监控系统。所有Kafka速率度量都有相应的后缀为-total的累积计数度量，如records-consumed-rate累计度量为records-consumed-total。查看可用指标的最简单方法是启动jconsole并将其指向正在运行的kafka客户端或服务器;这将允许使用JMX浏览所有指标。
    Apache Kafka默认禁用远程JMX。我们可以为使用CLI或标准Java系统属性启动的进程设置环境变量JMX_PORT，以编程方式启用远程JMX，从而使用JMX启用远程监控。在生产场景中启用远程JMX时，必须启用安全性，以确保未经授权的用户不能监视或控制代理或应用程序以及运行这些应用程序的平台。在Kafka中，默认情况下JMX的身份验证是禁用的，在生产部署中，安全配置必须被覆盖，方法是为使用CLI启动的进程设置环境变量KAFKA_JMX_OPTS，或者设置适当的Java系统属性。关于使用JMX设置参考https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html 。各种详细的监控点可以查看http://kafka.apache.org/documentation/#monitoring 。
    kafka目前在安全上支持一下选项：
    1.使用SSL或SASL从客户端(生产者和消费者)、其他broker和工具验证到broker的连接。kafka支持的SASL机制有：
        1).SASL/GSSAPI(Kerberos)——从版本0.9.0.0开始
        2).SASL/PLAIN-从版本0.10.0.0开始
        3).SASL/SCRAM-SHA-256和SASL/SCRAM-SHA-512-从0.10.2.0版本开始
        4).SASL/OAUTHBEARER -从2.0版开始
    2.从broker到ZooKeeper的连接验证
    3.使用SSL在broker和客户端之间、broker之间或broker和工具之间传输的数据加密(请注意，启用SSL会导致性能下降，其程度取决于CPU类型和JVM实现)。
    4.客户端读写操作的授权
    5.授权是可插入的，并且支持与外部授权服务集成
    在kafka中安全性是可选的——支持不安全的集群，以及经过身份验证、未经身份验证、加密和未加密的客户机的混合。默认情况下kafka的SSL机制是关闭的，如果要使用SSL进行加密传送，那么我们应该先有SSL key以及证书，因为kafka现在一般要求通过Java keytool命令行的方式生成keystores，并将所有的key和证书都存储在里面，在将来kafka要求是用PKCS12进行加密，因此命令行的方式如下：
    keytool -keystore {keystorefile} -alias localhost -validity {validity} -genkey -keyalg RSA -storetype pkcs12
    其中keystorefile是用来存放生成的keystore的路径，validity表示这个key的有效时间，它与证书的有效时间不一样，比如它的有效时间为10年，而证书的有效时间为1年，那么它可以先后包含10个证书。证书的生成Java命令行如下：
    keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -keyalg RSA -destkeystoretype pkcs12 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}
    这些命令行的执行都是在需要生成的broker上执行的，其中-ext参数是用来指定主机信息的，如果不需要，可以省略掉。对于hostname的检查主要是为了防止中间人的网络攻击，同时也是为了验证客户端是否连接到正确的broker上面，在kafka2.0.0以后这个hostname就开启了，我们也可以通过以下命令：

bin/kafka-configs.sh --bootstrap-server localhost:9093 --entity-type brokers --entity-name 0 --alter --add-config "listener.name.internal.ssl.endpoint.identification.algorithm="

来关闭hostname检测，即设置listener.name.internal.ssl.endpoint.identification.algorithm为空字符串。在开启hostname验证后，客户端可以检测Common Name (CN)或Subject Alternative Name (SAN)来验证服务端，当然SAN字段更加灵活，允许在一个证书中声明多个DNS和IP条目。使用命令如下：

keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey -keyalg RSA -destkeystoretype pkcs12 -ext SAN=DNS:{FQDN},IP:{IPADDRESS1}

关于配置kafka安全验证的各种授权方式可以参考官网http://kafka.apache.org/documentation/#security 。