秒杀场景核心的问题是如何解决海量请求带来的性能问题，那么我们如何在有限的资源下，尽最大的限度去提高服务器访问性能？按照我以往的经验，我大致总结有这几点：热点数据处理、流量削峰、资源隔离、服务器优化。

Vue2，便心生焦虑，心想，总不可能仅限于此吧....我要跟上大前端的步伐。大前端一直保持着欣欣向荣且充满活力的态势，Vue3、Vite、React、Ts、Fluter、Nodejs、React

同一Partition的Replica不应存储在同一个Broker上，因为一旦该Broker宕机，对应Partition的所有Replica都无法工作，这就达不到高可用的效果

值得一提的是，它还具有视频和语音通话功能，使远程协作更上一层楼。每当您想与同事交谈时，都可以直接从JetBrains

年去过的丽江古城，整个古城里面卖东西的基本上没几个本地人（我感觉大部分是外地过来做生意的），卖的东西大部分也全国各地都能买到，根本感受不到这里的文化气息，反而充满了浓浓的经商味道。

如上图所示，你的数据源被代理后，通过被DataSourceProxy代理后，你所执行的sql，会被提取，解析，保存前镜像后，再执行业务sql，再保存后镜像，以便与后续出现异常，进行二阶段的回滚操作。

我那时候转行自学，完全就是凭借着那股不服就是肝的冲劲，我记得当时给了自己一个成语贴在电脑旁，这个成语是：破釜沉舟。每天看着这个成语埋头自学，我知道自己没有退路了，唯有坚持下去，而且我也始终坚信

跟随者收到请求投票信息后，如果该候选人符合投票要求后，则将自己宝贵（因为每个任期内跟随者只能投给先来的候选人一票，后面来的候选人则不能在投票给它了）的一票投给该候选人，同时更新任期编号。

前后逻辑一致，数据不要自相矛盾，有逻辑漏洞，大厂面试官一般会根据你简历的总体内容大致做一个判断，逻辑有错误会对面试者诚实度打折，这在很多公司是大忌，相信大家都听过阿里的价值观；

System.out.println("=====================================thread-pool-info:"

13、异常的意思是从节点不可用，那么为什么会导致从节点不可用？这里从节点不一定挂了，而是因为从节点的消费偏移量落后主节点太多导致的，以下这篇文章详细地解读了产生这个异常报错的原因：

面完之后补了一轮笔试题，题目是从阿里内部题库出的，大体上会出两道题目，一道是实现一个功能，一道是算法题，具体是什么题目就不方便透露了，通过这次笔试的体验，我觉得阿里的笔试会比较注重实际场景，而不是从

版本对消息格式进行了大幅度重构，使用可变长度解决了空间使用率低的问题，增加了消息总长度字段，使用增量的形式保存时间戳和位移，并且把一些字段统一抽取到消息集合中，下面我们来看下

Record，并以自定义的格式序列化成二进制字节数组进行保存：如上图所示，消息严格按照顺序进行追加，一般来说，左边的消息存储时间都要小于右边的消息，需要注意的一点是，在

http://localhost:4000：如果能够向上面这样正常打开，则说明博客已经在本地启动成功了！编写文章可以快速地使用以下命令创建一篇文章：hexo

的消费线程模型进行优化：1、细化消息顺序粒度之前的做法是将每个分区单独一条线程消费，无法再继续在分区之上增加消费能力，我们知道业务方发送顺序消息时，会将同一类型具有顺序性的消息给一个相同的

kafkaProperties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,

leader）max.request.size=5242880buffer.memory=268435456在生产环境的一台服务器上，使用以上参数对集群进行生产发送性能压测：从上图可以看到，使用平均

异步发送消息居然也会阻塞？」中提到了缓冲池，后面再经过一番阅读源码后，发现了这个缓冲池设计的很棒，被它的设计思想优雅到了，所以忍不住跟大家继续分享一波。在新版的

disabled.大概的意思是：当缓冲池的内存块用完后，消息追加调用将会被阻塞，直到有空闲的内存块。由于性能监控项目每分钟需要发送几百万条消息，只要

重启过程中，产生了大量如下日志：发现大量主题索引文件损坏并且重建索引文件的警告信息，定位到源码处：kafka.log.OffsetIndex#sanityCheck按我自己的理解描述下：Kafka

{"partitions":[{"topic":"test-topic","partition":0}]}（2）分区重分配#

模块中的代码需要进行优化，使得代码更加优雅，交互逻辑更加清晰易懂，本着

中实现顺序消费，那么需要保证同一类消息放入同一个线程当中，我用如下图表示：但需要注意的是，以上仅仅是保证正常情况下能够实现顺序消费，如果期间出现重平衡等异常情况，就会导致消费顺序被打乱，不过本身像

上两篇文章都在讨论顺序消息的一些知识，看到有个读者的留言如下：这个问题问得非常棒，由于在之前的文章中并没有提及到，因此我在这篇文章中单独讲解，本文将从消费顺序性这个问题出发，深度剖析

取模得出的分区号就不一样了，第三条消息路由到其它分区，结果就是这三条顺序消息就不在同一个分区了，此时就不能保证这三条消息的消费顺序了。2、分区不变更2.1、分区单副本假设此时集群有两个分区的主题

顺序消息的一些理解吧，如有理解不对的地方麻烦留言指点一下。通常我们在说顺序消费指的是生产者按照顺序发送，消费者按照顺序进行消费，听起来简单，但做起来却非常困难。我们都知道无论是

重启过程中，产生了大量如下日志：发现大量主题索引文件损坏并且重建索引文件的警告信息，定位到源码处：kafka.log.OffsetIndex#sanityCheck按我自己的理解描述下：Kafka

lastOffset，源码注释如下：其中最关键的描述是：它可以是也可以不是第一条记录的偏移量。kafka.log.OffsetIndex#append以上是追加索引块核心方法，在这里可以看到

发生重平衡的有以下几种情况：消费组成员发生变更，有新消费者加入或者离开，或者有消费者崩溃；消费组订阅的主题数量发生变更；消费组订阅的分区数发生变更。在第

方法中主要是使用了单例模式构造配置实现类，它的构造具体实现如下：io.seata.config.ConfigurationFactory#buildConfiguration：首先从

方法：io.seata.spring.annotation.GlobalTransactionScanner#initClientTMClient.init(applicationId,

参数来删除，因此会出现日志未过期，磁盘写满的情况。针对该集群双十一会遇到某些挂载磁盘被写满的情况，需要手动对主题进行删除以清空磁盘的操作，现在分析删除主题对集群以及客户端会有什么影响，以及

Bean从源码的角度解析线程池运行原理关于线程池你不得不知道的一些设置你都理解创建线程池的参数吗？Java并发之AQS源码分析（二）Java并发之AQS源码分析（一）长按可以订阅

开始同步消息，避免了消息不一致/离散的问题。近期热文我对支付平台架构设计的一些思考分布式事务中间件Seata的设计原理聊聊Tomcat的架构设计Kafka

上，该监听器就会被触发，然后执行分区重分配逻辑：kafka.controller.KafkaController.PartitionReassignment：该监听器会将正在迁移的

由于这个频繁断开重连，并不是开发人员开发过程中导致的，考虑到双十一临近，不能贸然升级改动项目，那么现在最好的方案就是对集群进行水平扩展，增加集群的负载能力，并对专门的主题进行分区重分配。

之前有很多网友加我好友，问我有没有一些技术交流群，加上之前文章很多都是解答网友而写的，这也说明互相交流是学习最有效的方法，也应网友的要求，我为公众号开了一个学习交流群，目的是打造一个纯后端交流技术圈，有兴趣的朋友可以在扫描下方二维码，或者公众号回复「加群」，或者在公号

在消费者启动时，某些参数会影响重平衡机制的发生，所以需要根据业务的属性，对这些参数进行调优，否则可能会因为设置不当导致频繁重平衡，严重影响消费速度，下面跟大家说说这几个参数的一些要点：

max.message.bytes，它只针对某个主题生效，可动态配置，可覆盖全局的

org.apache.rocketmq.client.consumer.store.RemoteBrokerOffsetStore#updateOffset:

responseHeader.setSuggestWhichBrokerId(subscriptionGroupConfig.getWhichBrokerWhenConsumeSlowly());}

HAConnection.this.haService.getDefaultMessageStore().getCommitLogData(this.nextTransferFromWhere);

AbstractRecords.estimateSizeInBytesUpperBound(apiVersions.maxUsableProduceMagic(),

为空，则新建一个，从名字可知道，订阅信息是按照消费组进行存放的，因此在更新订阅信息时，订阅信息是按照消费组存放的，这步骤就会导致同一个消费组内的各个消费者客户端的订阅信息相互被覆盖。消息拉取在

协议自身的特点，它会造成事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，因此它性能很差，它的存在相当于七伤拳那样“伤人七分，损己三分”，因此在互联网项目中并不是很流行这种解决方案。

我发现数据库有些日期居然用字符串保存？于是跟几个小伙伴讨论了关于数据库的日期应该要怎么保存的问题，其实我一直都建议直接用数值保存时间戳，为什么我要这么建议呢？以下，我会从时区的概念来跟你们解释一下，为什么用数值保存时间戳是最好的方案，同时也为了分享出来，让更多开发小伙伴留意这些细节性的东西。相信时区对于很多人来说的很熟悉，因为地球是圆的，在地球上不同角落看到的太阳上升的角度都是不同的，即每个人对于时间的显示都是不一样的，举个例子：此时处于东

作为后端开发者，难免要经常与服务器打交道，部署项目，查看日志，排查问题等等，除了开发工作，其余时间基本都在终端上，那么你是怎么连接上服务器的呢？直接粗暴地用账号密码？但是直接用账号密码连接服务器存在安全风险，因为服务器有多人拥有权限，在密码拷贝给各个成员过程中，非常容易暴露出去，所以通常我们是通过