一、前言 随着项目不断壮大，OOM（Out Of Memory）成为bugly上的疑难杂症之一，大部分业务开发人员对于线上OOM问题一般都是暂不处理，一方面是因为OOM问题没有足够的log，无法在短期

这次天池 PolarDB 数据库性能大赛竞争相当激烈，眼睛一闭一睁成绩就会被血洗，最后榜单成绩是第三名，答辩翻车了，最终取得了大赛季军。云计算领域接触的是最前沿的技术，阿里云的 PolarDB 作为云原生数据库里程碑式的革新产品，也为这次比赛提供了最先进的硬件环境。 为了充分使…

之前组内一位大佬分享了一些关于系统性能优化方面的干货，这里我将它整理成文并且加入自己平时常用的一些工具和技巧。由于关于系统性能优化涉及的内容非常多，我会分几篇文章来分享。这次分享下定位系统层面问题的常用方法。 吞吐量越高，延迟会越大。因为请求量过大，系统太繁忙，所以响应时间会降…

开发工作中对于分布式缓存高可用方案（搭建Redis缓存高可用方案），Redis主从架构下是如何保证高可用的呢？我们知道是应用了哨兵机制来实现。那Redis服务部署的哨兵模式主要是什么，又解决了什么问题

国际惯例，先报成绩，熬了无数个夜晚，最后依旧被绝杀出了第一页，最终排名第 21 名。前十名的成绩分布为 413.69~416.94，我最终的耗时是 422.43。成绩虽然不是特别亮眼，但与众多参赛选手使用 C++ 作为参赛语言不同，我使用的是 Java，一方面是我 C++ 的能…

天池中间件大赛的初赛在今早终于正式结束了，公众号停更了一个月，主要原因就是博主的空余时间几乎全花在这个比赛上，第一赛季结束，做下参赛总结，总的来说，收获不小。 先说结果，最终榜单排名是第 15 名（除去前排大佬的两个小号，加上作弊的第一名，勉强能算是第 12 名），说实话是挺满…

维持了 20 天的复赛终于告一段落了，国际惯例先说结果，复赛结果不太理想，一度从第 10 名掉到了最后的第 36 名，主要是写入的优化卡了 5 天，一直没有进展，最终排名也是定格在了排行榜的第二页。痛定思痛，这篇文章将自己复赛中学习的知识，成功的优化，未成功的优化都罗列一下。 …

这次天池中间件性能大赛初赛和复赛的成绩都正好是第五名，本次整理了复赛《单机百万消息队列的存储设计》的思路方案分享给大家，实现方案上也是决赛队伍中相对比较特别的。 实现一个进程内的队列引擎，单机可支持100万队列以上。 实现消息put、get接口。 在规定时间内完成数据发送、索引…

翻了一下公众号已经快两个月没有认真的写一篇文章了，这段时间主要是再忙阿里中间件的复赛，再加上前段时间团队旅游，所以才拖到现在开始写复赛的总结。首先先贴下成绩吧： 对接口层而言，消息包括两个字段，一个是业务字段a，一个是时间戳，以及一个byte数组消息体。实际存储格式用户自己定义…