内存溢出和内存泄漏其实学习jvm 的垃圾回收，基本上就是在解决这两类问题——内存泄漏和溢出，泄露了就得存代码角度去解决这个问题；如果不是因为泄漏导致的溢出，那就得去调整参数或者升级配置了。gc 可以回收的话就不会内存溢出，但是频繁GC 可能导致性能问题对象的内存分配在java虚拟机的自动内存分配机制下，一般不容易出现内存泄漏问题。但是写代码难免会遇到一些特殊情况，比如OOM神马的。。尽管虚拟机内存

今天下载了一个前端项目，想看看，运行的时候发现报错如下,然后尝试了很多方法，例如将文件夹node_modules 删除，再执行 npm/cnpm install 进行重新安装，折腾了很久这里记录一下sh: vue-cli-service: command not foundnpm ERR! code 127npm ERR! path /Users/liuwenqiang/workspace/vue

幂等生产者幂等”这个词原是数学领域中的概念，指的是某些操作或函数能够被执行多次，但每次得到的结果都是不变的在命令式编程语言（比如 C）中，若一个子程序是幂等的，那它必然不能修改系统状态。这样不管运行这个子程序多少次，与该子程序关联的那部分系统状态保持不变。在函数式编程语言（比如 Scala 或 Haskell）中，很多纯函数（pure function）天然就是幂等的，它们不执行任何的 side

Consumer 拦截器前面我们详细介绍了拦截器的原理，可以参考kafka系列之Producer 拦截器(06),其实拦截器的在很多技术中都有，关于拦截器的应用场景我们在前面一节中也介绍过了，这一节我们直接看一下消费者端拦截器的使用。我觉得为了学习kafka ，你可以打开kafka 的源码包，看看都有什么，你可以从kafka-client 包开始我们今天要介绍的ConsumerIntercepto

分区 Partition分区的意义提高负载均衡的能力kafak 通过分区来提高系统的负载均衡能力,主要通过以下两个方面进行保证的Kafka 创建Topic 的时候使得分区均匀的分布在各个Broker(集群节点)上kafka 在生产者发送消息到kafka 集群的时候，通过一定的负载均衡策略，使得数据均匀的分布在各个分区上这样通过在两个层面上的保证，从而保证了集群整体的负载均衡实现系统的高伸缩性（Sc

概论什么是消息中间件举个例子，生产者消费者，生产者生产鸡蛋，消费者消费鸡蛋，生产者生产一个鸡蛋，消费者就消费一个鸡蛋，假设消费者消费鸡蛋的时候噎住了（系统宕机了），生产者还在生产鸡蛋，那新生产的鸡蛋就丢失了。再比如生产者很强劲（大交易量的情况），生产者1秒钟生产100个鸡蛋，消费者1秒钟只能吃50个鸡蛋，那要不了一会，消费者就吃不消了（消息堵塞，最终导致系统超时），消费者拒绝再吃了，”鸡蛋“又丢失

kafka 重试机制重试源码首先我们从KafkaProducer的send 方法入手我们看到其实客户端是不会直接发送数据的，而是将其加入到了一个缓存里面去，然后根据缓存的情况(result)判断要不要发送，发送也只是唤醒sender 对象RecordAccumulator.RecordAppendResult result = accumulator.append(tp, timestamp, s

Coordinator与消费者在数据库设计过程中，我们经常会有这样的情况下某个基础表会被多个视图或者存储过程引用修改基础表的时候，我们必须小心翼翼地，因为不会有任何提示告诉我们，如果继续修改，会不会造成视图或者存储过程有问题即便我们知道有问题，我们也没有办法去让视图和存储过程刷新得到表最新的信息如果你在创建视图中使用了select *,就会导致各种各样的bug"协调者"有些陌生，所谓协调者，在 K

概要当我们发送消息之前，先问几个问题：每条消息都是很关键且不能容忍丢失么？偶尔重复消息可以么？我们关注的是消息延迟还是写入消息的吞吐量？举个例子，有一个信用卡交易处理系统，当交易发生时会发送一条消息到Kafka，另一个服务来读取消息并根据规则引擎来检查交易是否通过，将结果通过Kafka返回，对于这样的业务，消息既不能丢失也不能重复，由于交易量大因此吞吐量需要尽可能大，延迟可以稍微高一点。再举个例子

Producer 拦截器拦截器(interceptor)是个相当新的功能，它是在Kafka 0.10版本被引入的，主要用于实现clients端的定制化控制逻辑。拦截器作为一个非常小众的功能，Kafka 拦截器自 0.10 版本被引入后并未得到太多的实际应用。Kafka 拦截器可以应用于包括客户端监控、端到端系统性能检测、消息审计等多种功能在内的场景，对于监控我们其实是利用拦截器实现了埋点类似的功能