mq和rpc调用的区别是什么？
mq和rpc的区别往大了说属于数据流模式（dataflow mode）的问题。我们常见的数据流有三种：1. 通过数据库；2. 通过服务调用（REST/RPC）; 3. 通过异步消息传递（消息引擎，如Kafka） RPC和MQ是有相似之处的，毕竟我们远程调用一个服务也可以看做是一个事件，但不同之处在于：
- MQ有自己的buffer，能够对抗过载（overloaded）和不可用场景
- MQ支持重试
- 允许发布/订阅模式 当然它们还有其他区别。应该这样说RPC是介于通过数据库和通过MQ之间的数据流模式。
Broker端参数
静态参数（Static Configs)
所谓静态参数，是指你必须在Kafka的配置文件server.properties中进行设置的参数，不管你是新增、修改还是删除。同时，你必须重启Broker进程才能令它们生效。而主题级别参数的设置则有所不同，Kafka提供了专门的kafka-configs命令来修改它们。
Topic级别参数的设置就是这种情况，我们有两种方式可以设置：
创建Topic时进行设置 修改Topic时设置 我们先来看看如何在创建Topic时设置这些参数。我用上面提到的retention.ms和max.message.bytes举例。设想你的部门需要将交易数据发送到Kafka进行处理，需要保存最近半年的交易数据，同时这些数据很大，通常都有几MB，但一般不会超过5MB。现在让我们用以下命令来创建Topic：
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic transaction --partitions 1 --replication-factor 1 --config retention.ms=15552000000 --config max.message.bytes=5242880 我们只需要知道Kafka开放了kafka-topics命令供我们来创建Topic即可。对于上面这样一条命令，请注意结尾处的--config设置，我们就是在config后面指定了想要设置的Topic级别参数。
下面看看使用另一个自带的命令kafka-configs来修改Topic级别参数。假设我们现在要发送最大值是10MB的消息，该如何修改呢？命令如下：
bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name transaction --alter --add-config max.message.bytes=10485760 总体来说，你只能使用这么两种方式来设置Topic级别参数。我个人的建议是，你最好始终坚持使用第二种方式来设置，并且在未来，Kafka社区很有可能统一使用kafka-configs脚本来调整Topic级别参数。
Kafka JVM参数
KAFKA_HEAP_OPTS：指定堆大小。 KAFKA_JVM_PERFORMANCE_OPTS：指定GC参数。 比如你可以这样启动Kafka Broker，即在启动Kafka Broker之前，先设置上这两个环境变量：
$> export KAFKA_HEAP_OPTS=--Xms6g --Xmx6g $> export KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true $> bin/kafka-server-start.sh config/server.properties
kafka 操作系统参数
文件描述符限制 ulimit -n 文件系统类型 XFS的性能要强于ext4 Swappiness 提交时间
Swappiness 一旦设置成0，当物理内存耗尽时，操作系统会触发OOM killer这个组件，它会随机挑选一个进程然后kill掉，即根本不给用户任何的预警。但如果设置成一个比较小的值，当开始使用swap空间时，你至少能够观测到Broker性能开始出现急剧下降，从而给你进一步调优和诊断问题的时间。基于这个考虑，我个人建议将swappniess配置成一个接近0但不为0的值，比如1。
主流的I/O模型通常有5种类型：
阻塞式I/O 非阻塞式I/O I/O多路复用 信号驱动I O和异步I/O(其实很少有Linux系统支持，反而是Windows系统提供了一个叫IOCP线程模型属于这一种)
Kafka 带宽计算
机器使用带宽的 70% 以上有丢包的可能性 预留可使用 带宽的 2/3 假设Kafka会用到70%(1 Gbps * 70% = 700Mb) 的带宽资源， 单台服务器使用带宽700Mb / 3 ≈ 240Mbps。 2/3其实是相当保守的，可酌情减少。
计算1小时内处理1TB数据所需的服务器数量:
我们每秒需要处理2336Mb的数据，除以240，约等于10台服务器。如果消息还需要额外复制两份，那么总的服务器台数还要乘以3，即30台。
在规划磁盘容量时你需要考虑下面这几个元素：
新增消息数 消息留存时间 平均消息大小 备份数 是否启用压缩
kafka 磁盘容量预估:
假设你所在公司有个业务每天需要向Kafka集群发送1亿条消息，每条消息保存两份以防止数据丢失，另外消息默认保存两周时间。现在假设消息的平均大小是1KB，那么你能说出你的Kafka集群需要为这个业务预留多少磁盘空间吗？
我们来计算一下：每天1亿条1KB大小的消息，保存两份且留存两周的时间，那么总的空间大小就等于1亿 1KB 2 / 1000 / 1000 = 200GB。一般情况下Kafka集群除了消息数据还有其他类型的数据，比如索引数据等，故我们再为这些数据预留出10%的磁盘空间，因此总的存储容量就是220GB。既然要保存两周，那么整体容量即为220GB 14，大约3TB左右。Kafka支持数据的压缩，假设压缩比是0.75，那么最后你需要规划的存储空间就是0.75 3 = 2.25TB。
总之在规划磁盘容量时你需要考虑下面这几个元素：
新增消息数 消息留存时间 平均消息大小 备份数 是否启用压缩
如何优化 Socket 通信
实现非阻塞I/O 高效的Reactor线程模型 串行设计 零拷贝
TCP参数配置项
TCP_NODELAY：TCP_NODELAY选项是用来控制是否开启Nagle算法。Nagle算法通过缓存的方式将小的数据包组成一个大的数据包，从而避免大量的小数据包发送阻塞网络，提高网络传输的效率。我们可以关闭该算法，优化对于时延敏感的应用场景。
SO_RCVBUF和SO_SNDBUF：可以根据场景调整套接字发送缓冲区和接收缓冲区的大小。
SO_BACKLOG：backlog参数指定了客户端连接请求缓冲队列的大小。服务端处理客户端连接请求是按顺序处理的，所以同一时间只能处理一个客户端连接，当有多个客户端进来的时候，服务端就会将不能处理的客户端连接请求放在队列中等待处理。
SO_KEEPALIVE：当设置该选项以后，连接会检查长时间没有发送数据的客户端的连接状态，检测到客户端断开连接后，服务端将回收该连接。我们可以将该时间设置得短一些，来提高回收连接的效率。
