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