开源基础软件社区

前言GitHub应该是广大开发者最常去的站点，这里面有大量的优秀项目，是广大开发者寻找资源，交友学习的好地方。尤其是前段时间GitHub公布了一项代码存档计划——ArcticCodeVault，要把代码埋入地下250米深的永久冻土层，可以将代码保存一千年。此外，GitHub还为开发者在配置文件中设计了纪念徽章。想想自己的代码可以作为人类的技术瑰宝被保存一千年，是不是有点自豪呢。好了，言归正传。虽然GitHub没有被Q，但是由于CDN服务器...

背景最近有个学弟找到我，跟我描述了以下场景：他们公司内部管理系统上有很多报表，报表数据都有分页显示，浏览的时候速度还可以。但是每个报表在导出时间窗口稍微大一点的数据时，就异常缓慢，有时候多人一起导出时还会出现堆溢出。他知道是因为数据全部加载到jvm内存导致的堆溢出。所以只能对时间窗口做了限制。以避免因导出过数据过大而引起的堆溢出。最终拍脑袋定下个限制为：导出的数据时间窗口不能超过1个月。虽然问题解...

前言大家在项目中肯定有碰到过​​Maven​​的Jar包冲突问题，经常出现的场景为：本地运行报​​NoSuchMethodError​​，​​ClassNotFoundException​​。明明在依赖里有这个Jar包啊。怎么运行不了！？项目中明明定义着某个jar包版本为​​2.0.2​​，怎么打包之后变成​​2.5.0​​了！？A项目引xxx.jar包运行好好的，B项目同样引入xxx.jar后，运行报错了。。是B项目有问题，还是xxx.jar包有问题！？本地环境和测试环境运行的...

前言本系列着重介绍​​Prometheus​​以及如何用它和其周边的生态来搭建一套属于自己的实时监控告警平台。本系列受众对象为初次接触​​Prometheus​​的用户，大神勿喷，偏重于操作和实战，但是重要的概念也会精炼出提及下。系列主要分为以下几块​​Prometheus​​​各个概念介绍和搭建，如何抓取数据（​​一步步教你用Prometheus搭建实时监控系统系列(一)——上帝之火，普罗米修斯的崛起​​）如何推送数据至​​Prometheu...

上帝之火本系列讲述的是开源实时监控告警解决方案​​Prometheus​​，这个单词很牛逼。每次我都能联想到带来上帝之火的希腊之神，普罗米修斯。而这个开源的logo也是火，个人挺喜欢这个logo的设计。本系列着重介绍​​Prometheus​​以及如何用它和其周边的生态来搭建一套属于自己的实时监控告警平台。本系列受众对象为初次接触​​Prometheus​​的用户，大神勿喷，偏重于操作和实战，但是重要的概念也会精炼出提及下。系列主...

1.背景因为业务关系，要和许多不同第三方公司进行对接。这些服务商都提供基于http的api。但是每家公司提供api具体细节差别很大。有的基于​​RESTFUL​​​规范，有的基于传统的http规范；有的需要在​​header​​​里放置签名，有的需要​​SSL​​​的双向认证，有的只需要​​SSL​​​的单向认证；有的以​​JSON​​​方式进行序列化，有的以​​XML​​方式进行序列化。类似于这样细节的差别太多了。不同的公司API规范不...

1.为什么需要控制加载顺序​​springboot​​​遵从约定大于配置的原则，极大程度的解决了配置繁琐的问题。在此基础上，又提供了spi机制，用​​spring.factories​​可以完成一个小组件的自动装配功能。在一般业务场景，可能你不大关心一个bean是如何被注册进spring容器的。只需要把需要注册进容器的bean声明为​​Component​​即可，spring会自动扫描到这个Bean完成初始化并加载到spring上下文容器。而当你在项目启动时需要...

1.背景Spring的核心思想就是容器，当容器refresh的时候，外部看上去风平浪静，其实内部则是一片惊涛骇浪，汪洋一片。Springboot更是封装了Spring，遵循约定大于配置，加上自动装配的机制。很多时候我们只要引用了一个依赖，几乎是零配置就能完成一个功能的装配。我非常喜欢这种自动装配的机制，所以在自己开发中间件和公共依赖工具的时候也会用到这个特性。让使用者以最小的代价接入。想要把自动装配玩的转，就必须要了解spring...

背景公司线上有个tomcat服务，里面合并部署了大概8个微服务，之所以没有像其他微服务那样单独部署，其目的是为了节约服务器资源，况且这8个服务是属于边缘服务，并发不高，就算宕机也不会影响核心业务。因为并发不高，所以线上一共部署了2个tomcat进行负载均衡。这个tomcat刚上生产线，运行挺平稳。大概过了大概1天后，运维同事反映2个tomcat节点均挂了。无法接受新的请求了。CPU飙升到100%。排查过程一接手这个问题后。首先大...

在拥有大量并发用户的系统中，热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款，或许是海量用户突然涌入某个店铺，或许是秒杀时瞬间大量开启的爬虫用户，这些突发的无法预先感知的热key都是系统潜在的巨大风险。风险是什么呢？主要是数据层，其次是服务层。热key对数据层的冲击显而易见，譬如数据存放在redis或者MySQL中，以redis为例，那个未知的热数据会按照hash规则被存在于某个redis分片上，平时使用时都...

1命令行不知道大家在日常操作redis时用什么可视化工具呢？以前总觉得没有什么太好的可视化工具，于是问了一个业内朋友。对方回：你还用可视化工具？直接命令行呀，redis提供了这么多命令，操作起来行云流水。用可视化工具觉得很low。命令行的鄙视用工具的，用高端工具的鄙视低端工具的，鄙视链一直存在。虽然用命令行自己也可以，但是总感觉效率上不如用工具，在视觉上不那么直观。尤其是看json的时候，在命令行就很不友好。大...

一原本以为自己对redis命令还蛮熟悉的，各种数据模型各种基于redis的骚操作。但是最近在使用redis的scan的命令时却踩了一个坑，顿时发觉自己原来对redis的游标理解的很有限。所以记录下这个踩坑的过程，背景如下：公司因为redis服务器内存吃紧，需要删除一些无用的没有设置过期时间的key。大概有500多w的key。虽然key的数目听起来挺吓人。但是自己玩redis也有年头了，这种事还不是手到擒来？当时想了下，具体方案是通过lua脚本...

1前段时间，在网上看到一道面试题：如何用redis存储统计1亿用户一年的登陆情况，并快速检索任意时间窗口内的活跃用户数量。觉得很有意思，就仔细想了下。并做了一系列实验，自己模拟了下。还是有点收获的，现整理下来。和大家一起分享。Redis是一个内存数据库，采用单线程和事件驱动的机制来处理网络请求。实际生产的QPS和TPS单台都能达到3,4W，读写性能非常棒。用来存储一些对核心业务弱影响的用户状态信息还是非常不错的。对...

1以前在github发开源项目，都因为懒，从来不构建到中央仓库。最近因为其他人要用，联系我。希望可以发到中央仓库。我想，不就是mvndeploy嘛，开搞。一圈弄下来，发现真没那么简单。当中遇到了无数的坑，让我每一次都心里默默念到，发个项目，为何如此痛苦。现将痛苦的过程详细记录下来。希望可以帮助到其他小伙伴少踩点坑。首先，你需要到sonatype这个站点上去注册一个账号。这个页面长这个样子：我当时以为我进错地方了，这不...

1不知道各位在生产日志中定位问题时有没有碰到这样的场景：由于coding的时候日志输出的比较少，出现问题时，很难通过日志去定位到问题。又或者是，你明明coding的时候有输出日志。但是在庞大的日志文件中，由于业务线程并发比较多，你输出的日志又没有加关键信息。你也很难定位到你所需要的日志信息。之前在公司里写业务代码时，为了使每个RPC调用能被日志记录下来，我们在公司基础组件里定义了一个切面，拦截所有的RPC调用，方...

背景前不久，因为公司业务需要，需要解决在大促场景下后端业务的热点缓存问题，所以研究了下缓存热点解决方案。很多公司的缓存都是基于redis来做的，redis的性能其实已经足以能应付大部分的场景，但是对于大促期间或者活动抢购期间的某个爆品，可能会出现在几秒时间内流入大量的流量，由于某个爆品的数据在rediscluster场景下会按照hash规则被存放在某个redis分片上，那么这几秒的流量都会压到这个redis分片，从而在瞬间会导致...

前言最近在做TLog1.2.5版本的迭代，许多小伙伴之前也表示说很想参与开源项目的贡献。为了让项目更好更快速的迭代新特性以及本着发扬开源精神互相学习交流，很有幸招募到了很多小伙伴与我一起前行。为了方便大家理解TLog项目的核心原理和架构，便有了此篇内容。此篇内容偏向TLog技术设计和核心原理，同时也涵盖着做一个开源框架所需要考虑的问题和技术要点。我一直相信，好的技术内容应提领关键点，引导大家该去如何读懂源码。而...

前言最近一个朋友老是和我抱怨：公司系统日志打的实在是太烂了，有用的信息很少，没用的一大堆。就连那有用的信息，在那么多节点日志之间进行追查，也是痛苦的一笔。我问他，公司没有日志收集吗，日志收集起来看总好过一个节点一个节点日志查看。他表示，公司有接入一个收费第三方的日志产品，做了收集。但是仅仅是方便了统一化查看搜索，但是系统本身的日志缺少一些关键性的要素。比较乱，在很多微服务之间查看调用日志时定位...

前言在每个公司的系统中，总有一些拥有复杂业务逻辑的系统，这些系统承载着核心业务逻辑，几乎每个需求都和这些核心业务有关，这些核心业务业务逻辑冗长，涉及内部逻辑运算，缓存操作，持久化操作，外部资源调取，内部其他系统RPC调用等等。时间一长，项目几经易手，维护的成本得就会越来越高。各种硬代码判断，分支条件越来越多。代码的抽象，复用率也越来越低，各个模块之间的耦合度很高。一小段逻辑的变动，会影响到其他模块...

前言做java的人，一般IDE工具用的不是eclipse就是IntelliJIDEA了吧，eclipse因为是开源软件，而且起步比较早，功能也比较完善。早期基本上做java的使用eclipse都是必备技能。我工作十年多，直到2年前还在用eclipse，随着IntelliJIDEA的市场份额原来越大，很多人都转投这个更现代化，更懂开发者的IDE工具中。我也在两年前从eclipse阵营转投IntelliJIDEA的阵营了，同时把windows电脑也换成了mac。本身IntelliJ看起来就更现代化，...