Nginx与Kafka部署及原理解析-优快云博客

[root@nginx-kafka01 html]# systemctl start nginx
Job for nginx.service failed because the control process exited with error code. See "systemctl status nginx.service" and "journalctl -xe" for details.
[root@nginx-kafka01 html]# ps -ef|grep nginx
root       1712   1500  0 11:36 pts/0    00:00:00 grep --color=auto nginx
[root@nginx-kafka01 html]# nginx -t	#（检查语法--这里报错了）
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] open() "/var/log/nginx/sc/access.log" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed
[root@nginx-kafka01 html]# mkdir /var/log/nginx/sc
[root@nginx-kafka01 html]# nginx -t	#（修改后再次检查语法--成功）
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root@nginx-kafka01 ~]# nginx -s reload	#重新加载nginx（前提是nginx已经启动 不然会报错）

6、页面展示

输入IP地址，就能得到页面展示了。

注意：nginx做web网站的话只能够支持静态网页展示（本项目，为了测试）

页面内容可以通过编辑index.html文件进行修改。

二、fakfa

消息中间件消息中间件

中间件 :与主体的业务没有太多关系，仅仅只是作为中间的转发。比如网站是整个业务的主体，保证主体正常运行就行。日志收集和清洗不影响主体，网站是直观的创造价值，kafka只是通过它进行一定的分析，反补网站，让它更加的健康、灵活。
消息中间件：redis、rabbitmq、nsq、kafaka

消息中间件（kafka）作用：

实现业务的解耦；
边缘业务运行失败不会影响核心业务；
方便某个组件需要扩展其他东西。
流量削峰。
日志收集，方便后续处理。

1、为什么要引入kafka做日志统一收集？

故障发生时方便定位问题
日志集中管理，后续需要日志的程序直接从kafka获取日志即可。尽可能的减少日志处理对nginx的影响
这里引用kafka目的：

对于自己：学习，大公司都在用。
对于架构来说，模拟业务解耦的场景、以及做日志集中处理的场景，后面学习了mysql后会接入mysql的日志
对于业务：实现业务解耦、集中存放日志（tomcat日志、mysql日志、nginx日志），方便处理查看和分析；
日志作用：调试、测试、排错、用户行为分析（大数据）

2、kafka是典型的的生产者-消费者模型的软件

指的是由生产者将数据源源不断推送到消息中心，由不同的消费者从消息中心取出数据做自己的处理，在同一类别下，所有消费者拿到的都是同样的数据

3、消息中间件一般有两种通信模式：点对点、发布-订阅（kafka）

点对点：生产者消费者一一对应，消费者消费完，消息中间件就没有了。

发布-订阅：本质上也是一种生产消费者模式，不同的是，由订阅者首先向消息中心指定自己对哪些数据感兴趣，发布者推送的数据经过消息中心后，每个订阅者拿到的仅仅是自己感兴趣的一组数据。这两种模式是使用消息中间件时最常用的，用于功能解耦和分布式系统间的消息通信。

4、kafka专业术语

broker ：服务器节点。kafka集群包含一个或多个服务器，服务器节点名称就叫broker。 broker存储的是topic的数据
topic ：消息的类别。
partition： 分区——提高吞吐量，提高效率；一般来说有几个broker就有几个partition，支持并发读写；有多个partition的话，消息的顺序总体来说就跟原来不一样了，但在单独的partition 里面还是有顺序的；
replica 副本：kafka消息高可用的来源（就是完整的分区备份）

5、副本的选举（partition选举leader）

生产者跟partition的leader打交道的，leader同步到follwer里面去。消费者去leader里面去消费。follwer仅仅只是用来备份。leader挂了后follower之间就要重新选举leader。leader挂了才会重新选举。

6、ISR（ in-sync-replica ）集合列表。

需要同步的follower集合，比如说5个副本，1个leader，都在ISR里面有一条消息来了，leader 怎么知道要同步哪些副本呢？根据ISR来。如果一个follower挂了，那就从这个列表里面删除了。如果一个follower卡住或者同步过慢，他也会从ISR里删除

7、数据的一致性保持

取决于生产者，生产者数据写入kafka一般都会有一个标志位，通过request.required.acks来设置数据可靠性的级别：

ack=0 发送过去就行，不管leader是否接受收成功
ack=-1 发送过去leader收到过后，就代表接收成功
ack=1 （默认） leader收到过后写入follower后，才算接收成功

kafka是如何保持数据的一致性？

消费组

多个消费者组成一个大的消费组来消费一类消息。

8、kafka是如何保证高可用的？

副本层面：多个broker+多个partition+多个replica
机器层面：ISR机制

消费者的offset

        假设分区的副本为3，其中副本0是 Leader，副本1和副本2是 follower，并且在 ISR 列表里面。虽然副本0已经写入了 Message3，但是 Consumer 只能读取到 Message1。因为所有的 ISR 都同步了 Message1，只有 High Water Mark 以上的消息才支持 Consumer 读取，而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区，对应于上图的副本2，这个很类似于木桶原理。

        这样做的原因是还没有被足够多副本复制的消息被认为是“不安全”的，如果 Leader 发生崩溃，另一个副本成为新 Leader，那么这些消息很可能丢失了。如果我们允许消费者读取这些消息，可能就会破坏一致性。试想，一个消费者从当前 Leader（副本0）读取并处理了 Message4，这个时候 Leader 挂掉了，选举了副本1为新的 Leader，这时候另一个消费者再去从新的 Leader 读取消息，发现这个消息其实并不存在，这就导致了数据不一致性问题。

        当然，引入了 High Water Mark 机制，会导致 Broker 间的消息复制因为某些原因变慢，那么消息到达消费者的时间也会随之变长（因为我们会先等待消息复制完毕）。延迟时间可以通过参数 replica.lag.time.max.ms 参数配置，它指定了副本在复制消息时可被允许的最大延迟时间