一、出问题了过了个双休来到公司，同时发现Linux终端的服务器状态中根目录空间直接爆满100%，周五走之前根目录仅仅使用了59%，同时项目服务的后台不停的有日志打印，而且测试的小伙伴说系统登录不上去了。下面记录一下个人排查并解决这个问题的全过程。这个服务器部署了两个项目的后台服务，一个是在本机安装了.NETRuntime后部署的.NETWebAPI以及Dapr应用，另一个是Docker部署的Java项目（微服务），两组后台服务均使用到了消息队列，一组使用到了RabbitMQ，另一组则使用到了RabbitMQ和Kafka。二、首要怀疑因为看到后台不停的打印出日志，后台日志服务使用到了Kafka，
一、出问题了过了个双休来到公司，同时发现Linux终端的服务器状态中根目录空间直接爆满100%，周五走之前根目录仅仅使用了59%，同时项目服务的后台不停的有日志打印，而且测试的小伙伴说系统登录不上去了。下面记录一下个人排查并解决这个问题的全过程。这个服务器部署了两个项目的后台服务，一个是在本机安装了.NETRuntime后部署的.NETWebAPI以及Dapr应用，另一个是Docker部署的Java项目（微服务），两组后台服务均使用到了消息队列，一组使用到了RabbitMQ，另一组则使用到了RabbitMQ和Kafka。二、首要怀疑因为看到后台不停的打印出日志，后台日志服务使用到了Kafka，
文章目录需求准备工作自定义复制策略编译代码需求使用MM2同步集群数据，topic名称不能变，默认的复制策略为：DefaultReplicationPolicy，这个策略会把同步至目标集群的topic都加上一个源集群别名的前缀，比如源集群别名为A，topic为：bi-log，该topic同步到目标集群后会变成：A.bi-log，为啥这么做呢，就是为了避免双向同步的场景出现死循环。官方也给出了解释：这是MirrorMaker2.0中的默认行为，以避免在复杂的镜像拓扑中重写数据。需要在复制流设计和主题管理方面小心自定义此项，以避免数据丢失。可以通过对“replication.policy.class
一、数据安全与Kerberos认证原理数据安全的概念数据安全=认证+授权授权是指用户可以访问的资源，比如：授权用户张三不能访问ods层的表，可以访问dwd层和dws层的表。再比如java中基于角色的身份认证RBAC（Role-BasedAccessControl）基于角色的权限控制。通过角色关联用户，角色关联权限的方式间接赋予。比如大数据中使用的Sentry和Ranger的授权框架的权限管理。认证主要是对用户的身份确认，比如最简单的用户的登录需要账户和密码；比如java的认证框架sa-token、Shiro、SpringSecurity等。hadoop官网的认证主要是使用麻省理工MIT的ker
一、数据安全与Kerberos认证原理数据安全的概念数据安全=认证+授权授权是指用户可以访问的资源，比如：授权用户张三不能访问ods层的表，可以访问dwd层和dws层的表。再比如java中基于角色的身份认证RBAC（Role-BasedAccessControl）基于角色的权限控制。通过角色关联用户，角色关联权限的方式间接赋予。比如大数据中使用的Sentry和Ranger的授权框架的权限管理。认证主要是对用户的身份确认，比如最简单的用户的登录需要账户和密码；比如java的认证框架sa-token、Shiro、SpringSecurity等。hadoop官网的认证主要是使用麻省理工MIT的ker
背景当kafka单机安装的时候或者集群安装的时候，kafka会先通过bootstrap.servers获取集群节点。有时候网络复杂的时候如内网外部署地址映射代理转发等bootstrap.servers配置地址可能为一个公网地址181.39.77.53:9092,然而返回的节点为内网地址172.16.31.33:9092，此时由于未开通172.16.31.33:9092网络，导致访问失败。此时通常有两种解决方案开通kafka返回节点的网络修改kafka连接方式，忽略返回的node节点信息，直接访问bootstrap.servers配置的地址这里主要介绍下方案二，直接访问bootstrap.ser
INFOOpeningsocketconnectiontoserver156.23.99.22/156.23.99.22:2181.WillnotattempttoauthenticateusingSASL 我以为是SASL认证的问题，经过2天的坑，发现是端口的问题。在启动kafka之前要先启动zookeeper1.启动zookeeper命令./usr/local/zookeeper/zookeeper-3.3.6/bin/zkServer.shstart2.启动好之后查看zookeeper端口号netstat-ntlp3.启动zookeeper时，会出现3个PID一样，这3个每次启动zook
文章目录springboot：整合Kafka一、环境配置依赖yaml配置二、springboot整合Kafka简单demo带回调的生产者分区策略验证默认分区策略自定义分区策略指定topic、partition、offset消费批量消费ConsumerAwareListenerErrorHandler异常处理器消息过滤器消息转发offset提交自动提交手动提交定时启动、停止监听器消费组别三、kafka的工具类springboot：整合Kafka一、环境配置依赖dependency>groupId>org.springframework.kafkagroupId>artifactId>spring
消息队列“消息队列”是在消息的传输过程中保存消息的容器。使用消息队列的好处：1）解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。2）可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。3）**缓冲：**有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致的情况。4）灵活性&峰值处理能力在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队
截至目前（2023年），Kafka的最新版本是2.9.0，发布于2022年11月30日。Kafka的历史版本可以在Kafka官方网站的下载页面中找到。Kafka从0.8版本开始发布，经历了多个版本的迭代和升级。以下是一些比较重要的Kafka版本及其发布年份：Kafka0.8：2013年Kafka0.9：2015年Kafka0.10：2016年Kafka0.11：2017年Kafka1.0：2018年Kafka2.0：2018年Kafka2.1：2018年Kafka2.2：2019年Kafka2.3：2019年Kafka2.4：2019年Kafka2.5：2020年Kafka2.6：2020年K
