挣扎的20届

问题定位：大量打印is not eligible for getting processed …… 涉及源码，源码真是越看越不能细看

背景 前面因为生成pinpoint慢就去了解了原理，一下子就把什么arthas、skywalking这种对于新手上路时，不可知不可学的东西贯通了。 中性的说，这类开源项目就是许多人维护了个基于jvm提

背景 生产/UAT环境，运维集成了pinpoint监控。后来出来个问题：项目启动非常慢从40秒变成了200秒 了解pinpoint原理 土味百度易得 ok，和预想差不多，代理方法，然后远端大数据持久化

背景 项目混合JAVA和C++ C++的业务脱敏就是监听xxx的发生，无状态得诚实执行计算 公司C++不太行，封闭不易连Redis集群，封闭不会连MQ，还懒狗不愿意做数据库CAS取事件的方案 形势比人

背景 生产环境, XXL-JOB, 会假死, 应用还活着 但已经不调度了 数据库为磐维分布式数据 定位 运维排查得知, 假死时数据库存在多xxl_job_info的锁表 存在几十个xxl_job_in

背景 开发人员自述: "这个修改(逻辑), 我修改草稿状态的就正常, 修改异常状态的就报错, 奇了怪了, 就多了一段查询逻辑, 我也加事务了啊" 代码逻辑复现见下文, 其中340为测试用主键,前端传递

背景: 选型其实没得选, 集团要求用磐维数据库 磐维为pg底层, 驱动类为 org.postgresql.Driver 问题: 建设末期, 要求接入监控统计功能, 接入现成产品xx指挥中心, 需额外引

背景: AndDB和GoldenDB, 原G库提供的是Mysql版本数据库,A库为PG版本数据库 G方存在严重可靠性问题, 扯皮大半年, 现在提供一个PG版本和新驱动 系统使用Kettle执行多库ET

背景: 建设是仓促的, 人是到处借的, 需求是一直变的, 排期是倒排的, 加上厂商b公司性价比招人完全没有建设能力了, 老员工一点点跑, 外包一点点招, 项目经理也是飘在天上只会要时间的 联调外部系统