谢怼怼
谢怼怼
暂无个人介绍
能力说明：
精通JVM运行机制，包括类生命、内存模型、垃圾回收及JVM常见参数；能够熟练使用Runnable接口创建线程和使用ExecutorService并发执行任务、识别潜在的死锁线程问题；能够使用Synchronized关键字和atomic包控制线程的执行顺序，使用并行Fork/Join框架；能过开发使用原始版本函数式接口的代码。
暂时未有相关云产品技术能力~
阿里云技能认证
详细说明上篇文章讲解了运维平台的整体设计，对各个部分并未深入介绍，今天将比较重要的一环——监控数据来源进行讲解。
在集群规模小，接入服务不多的情况下，我们一般都是通过命令或者客户端API的方式去运维Kafka，随着集群规模的增加，手动去运维的方式不利于我们统一运维Kafka集群和对接入服务进行管理。且对于高可用来说，缺少了很多例如：监控，告警，服务自愈等功能。
收到运维告警，数据库磁盘容量100%，一段时间后又降了下去，使用该数据库的服务是因为人员变动后流转到我手里维护的，当时听说过因为PostgreSQL问题进行了对应优化，优化前的表现也是类似将数据库临时表空间占满，所以我也想着从这方面入手排查，后续排查确实也验证了我的猜想。
摸鱼的时候看到某技术群里有一个问题和下面的回复
在某技术群里有人发了两条sql，问为什么性能有这么大的差距，下面是当时的问题
前一段时间，公司新切换到新的云服务提供商，切换过程还算顺利，新接到需求优化查询效率（详细优化过程查看上篇文章），需要新增索引，为了避免不必要的问题（害怕数据库服务是经过魔改的），向服务商咨询了新建索引是否支持Online DDL，然后发生了一次友好的技术交流
负责公司的用户收藏服务，收到调用方反馈有read time out的情况，进行排查发现是某用户收藏数量太多引起的（有业务设计上的问题，正常应只保留有限时间的收藏或者限制用户收藏的数量），一般用户收藏数是不超过100的，查询耗时是几毫秒，该用户收藏数2W+，查询耗时接近200毫秒。
发表了文章
2022-07-30
发表了文章
2022-07-24
发表了文章
2021-12-15
发表了文章
2021-09-30
发表了文章
2021-08-31
发表了文章
2021-08-30
发表了文章
2021-08-25
