使用了stackoverflow.com这么久，还没有登陆过，一直匿名。上周看了一个问题，很想一起解答一下，使用google账号登陆了，很方便。 刚开始没什么不同。当post完一个回答。我的个人头像下方出现了一个字样“new contributor”。好奇地点开头像，发现一会多了一个badge，editor。脑神经一会兴奋了起来。 当第二天回答第二个问题时，尝试首先自己在脑袋里用英语回答，然后借助谷歌翻译看机器翻译的回答。这个过程还挺有趣，弥补了自己英语只读不写不会表达的短板，慢慢地捡起来一些表达方式。 点滴帮助，可以让你自己在人群中慢慢发光。 借助国外问答平台，一方面可以巩固输出自己的知识，一方面可以提升自己的英语表达水平。
kafka有自己的rpc协议，即nio bytebuf中的数据格式，详见之前的kafka相关介绍的文章。这里我们来看一下大家常用，有时又疑惑的序列化反序列化，对应rpc协议中的records，kafka叫Serdes，实际上也是字面上的意思serialize and deserialize。在程序中序列化就是toBinary，反序列化是fromBinary，存储和传输都是用二进制。 通过以上描述，我们知道序列化和反序列化的作用。我们来看kafka的实现。Serdes工厂类，和提供基本数据类型序列化。 一、先看基础的抽象 interface：Serializer 包括 configure，例如配置ChartSet字符集，serialize，序列化。 interface：Deserializer 同理。 再来看包装接口：Serde 指定了serializer和deserializer。 二、 实现类，以Serializer为例 提供了几大应用的实现，分别是common，connect，stream，也即对应了kafka一般场景、kafka抽数场景如debezium，kafka stream原生流计算。我们看common，主要是实现了基本的数据类型的序列化，举两个例子，Long和String。 从上我们知道实现Serialize类，主要做了toBinary动作。 三、包装类，工厂方法 这里看WrapperSerde 为静态内部类，有一批子类： 看其中一个常用的StringSerde 引入String序列化类和反序列化类。
上一篇，聊到mysql的timezone问题。我们一起看看js的Date类型是否有时区的问题。 记住一点：js 的new Date()使用的是utc时间，即比GMT+8少了8小时。所以当我们用一些控件，需要初始化设置时间时，注意会有时区的问题。 如果直接用console.log(new Date())可以看到是UTC时间。 怎样获取正确时区的时间呢？ 1、date.getFullYear()等方法，会默认使用浏览器的时区进行时间获取，即以用户所在时区为准。这样就解决了时区问题。 2、更多定制化的timezone，或复杂的时间计算，可以考虑使用moment.js等工具库。 开发中，为什么我们不用考虑时区问题？ 幸运的是，开发过程中，大多数的日期时间控件都支持指定value format，即时间的格式。例如el-date-picker，指定value-format=’yyyy-MM-dd’。当这样指定的时候实际上，控件已经帮你做了一件事。类似用如下的js表达： [date.getFullYear(), date.getMonth() + 1, date.getDate()].join(‘-‘).replace(/(?=\b\d\b)/g, ‘0’)
jdbc url时指定serverTimezone，是会话timezone，数据查询与写入以该timezone为准，默认为UTC，比我国的GMT+8少8小时，也可以在mysql server配置中设为指定的timezone。 会话timezone在哪起作用？ 三种时间数据格式： 1、datetime 以当前timezone写入，不存储timezone信息，写的时候是gmt+8，读的时候不清楚写时用的是utc还是gmt+8，看会话timezone的值为准，所以读写需要保持timezone一致才不会出错。 2、timestamp存1970年以来的时间戳，相当于可以根据timezone生成不同的日期时间。 3、存成长整型bigint，和timestamp类似，只是查库时，需要用函数转换，可读性不如timestamp。 结语 一般应用，为了读写不受时区影响，我们会存timestamp或长整型。而datetime可以用于那些不需要国际化的应用。
作者：徐志摩 假如我是一朵雪花， 翩翩的在半空里潇洒， 我一定认清我的方向 飞扬，飞扬，飞扬， 这地面上有我的方向。 不去那冷寞的幽谷， 不去那凄凉的山麓， 也不上荒街去惆怅 飞扬，飞扬，飞扬， 你看，我有我的方向！ 在半空里娟娟的飞舞， 认明了那清幽的住处， 等着她来花园里探望 飞扬，飞扬，飞扬， 啊，她身上有朱砂梅的清香！ 那时我凭籍我的身轻， 盈盈的，沾住了她的衣襟， 贴近她柔波似的心胸 消溶，消溶，消溶 溶入了她柔波似的心胸！ 读工大的微信公众号信息《假如我是一朵雪花*》有感 Allen，2022年春，厦门。
一、ACL检查流程解析 一起看一下kafka server的启动与监听流程： Kafka -> KafkaServer -> SocketServer、KafkaRequestHandler 其中KafkaServer做相关的初始化，包括SocketServer 与 handler pool。 SocketServer的start up流程 看一下acceptor acceptor实际执行流程：监听网络事件，提交给processor处理 看一下processor，截取KafkaServer代码：这边的numIoThreads就是配置的具体处理线程数量。KafkaApis封装具体的各api的处理逻辑，handler pool则是工作线程池。 看看kafkaApis 接着看pool中每个线程的while循环，从request队列拿一个请求，调用apis处理，结果发送给对应channel。 request的入队，见SocketServer，这里也可以看到acl使用的principal和sasl认证是同一个。 之前我们看到，在selector做channel初始化时，已经做了sasl认证。那acl在哪里处理？KafkaApis。以offset commit为例 看一下，这边的authorize，各api共用的方法。构建resource pattern，即资源描述，以及对应的操作。然后使用authorizer实现类进行处理。 看一下鉴权实现类AclAuthorizer，初始化，主要是zk相关的监听，因为token,user,acl都存在zk。 遍历每个action 每个action的检查，区分超管，否则根据acl进行匹配。使用acl 缓存，结合zk的linstener更新缓存。不管是否开启acl，都会去取acl缓存列表。 二、总结 kafka以事件、线程池的方式，对接口请求做处理。 每个api请求，都会做相关的acl校验，不管是否开启acl，都会去取acl缓存列表。差别在于是否使用acl cache map对action进行匹配，匹配本身是用遍历的方式，action不多的话，对吞吐的影响可以忽略不计。 网上有一篇性能测试：见这里
