读下源码,具体分析SpringBoot2.2版本后用@EnableConfigurationProperties + @PropertySource 指定配置文件时遇到的陨石坑
前情提要:
本来我是有在写一个自己的项目, 有一些配置类想将其配置变得优雅一些,就想着用配置文件的形式。也方便打包编译的时候快速切换不同环境。
由于是SpringBoot项目,那么用配置文件的形式呢,当然少不了@ConfigurationProperties 这个注解
使用了这个注解来将配置文件的值注入到配置类之中呢,我还不满足 ...
Read more »
我过了个这辈子最难忘的年,疫情时期急性阑尾炎被迫手术,说说感想
2020年春节,疫情爆发。
1月23号就启程从上海回长沙过年了。也买好了带好了口罩,本以为这次新年也会像以往一般。一家人坐在一起 其乐融融。
做了高铁到家后还是很正常的,但是刚回家没多久就出问题了…
解决死信队列消息过期非异步问题,RabbitMQ 延时消息更优解——插件大法(Docker版)
上一篇文章: RabbitMQ 死信机制真的可以作为延时任务这个场景的解决方案吗? 里最终得出的结论:
RabbitMQ 死信机制可以作为延时任务这个场景的解决方案
但是,由于 RabbitMQ 消息死亡并非异步化,而是阻塞的。所以无法作为复杂延时场景——需要每条消息的死亡相互独立这种场景 下的解决方案。
如果说,果真我的 ...
Read more »
RabbitMQ 死信机制真的可以作为延时任务这个场景的解决方案吗?
关于延时任务,在业务场景中实在是太常见了。比如订单,下单xx分钟未支付就要将订单关闭。 比如红包, XX分钟未抢,则红包失效。
那么说起延时任务的实现方案的话,可能有很多人第一时间会想到轮询,即设置定时任务,而稍有经验的开发者就知道。轮询这机制会给数据库带来很大压力,小业务当然无所谓。如果是大量数据要处理的业务用轮询肯定是不行的。而且你如果要保证高可用,就又得牵扯出分布式定时任务。怎么搞都很麻烦。
很多小机灵鬼知道可以用消息队列来实现。确实,MQ的异步性和解耦性在延时任务的这种场景下可以爆发出很强的战斗力。而 RabbitMQ 因其被广泛使用,关于如何实现延时任务自然也有其解决方案…
说起来可能有点奇怪,我写了个 NodeJS 爬虫
nodejs 这玩意,写法基本上和 js 是差不多的。
想着到时候微服务跨语言调用的时候说不准也能有机会用到,就看了看。
也挺简单的,如果是指增删改查之类的话。
不过起个服务、写写增删改查着实没意思,所以今天写了个爬虫玩玩
git地址: https://github.com/skypyb/anime-spider
运行起来(如果你的 ...
Read more »
博客建站两周年整,2019总结。又到了这个时间啊–Merry Christmas!
说到2019,我在这里就可以下个定义。肯定是我人生中最令人难忘的一年之一。
以悲剧/滑稽一点的说法说: 我在今年算是成为了一个10级残疾( 最低等级)。 最骚的是还是我自己作死导致的,只能打落牙齿往肚子里咽。
乐观点的话可以说: 也就受了个法定意义上的轻伤,床上躺了三个月整而已。
哎,腰椎骨折,说事情大也大。但实际上在日常生活上我和以前的生活也并没有感到什么差别。
我也在有意志的控制自己,表现得的正常人一样。
不过这辈子是搬不了重物了。医生也说了,除了一些腰背部肌肉的锻炼外,和游泳外。不建议我做任何其他的锻炼…
谈谈如何优雅的写代码 (框架、工具类、SDK骚操作指南)——灵性的泛型
相信泛型做 Java 开发的都不陌生,也是天天接触的玩意了。不过真正自己写代码玩泛型玩的比较溜的我看还是比较少的。
基础应用、泛型是什么 这些东西就不说了。J2EE的东西到处都有,而且在职的 Java 开发看这种基础肯定没什么意思。
这篇主要就说一些泛型相关的骚操作。把泛型,给他玩的灵性起来。
...
Read more »
开坑 —— 谈谈如何优雅的写代码 (框架、工具类、SDK骚操作指南)
引言
这篇主要表明先开个坑, 后续能填多少是多少。反正坑也有几个没填完的。
比如: 探秘分布式解决方案啦(目前4篇) 微服务组件使用啦(目前10篇) — [ 2019-12-15数据 ] 慢慢来吧。
目前想法是能写出这么几篇文章: 泛型骚操作、枚举骚操作、链式调用法设计、将 Java8 的Stream终止操作玩出花、解 ...
Read more »
探秘分布式解决方案: 分布式ID——论高可用全局ID的诞生之道
为了解决在分布式系统中需要对某个资源进行全局的一个非重复ID生成,所以有了分布式ID这么一个概念
在分布式应用下,像分库分表的这种场景是很常见的, 这个时候如果还是用数据库本身的自增的话,那多个数据库ID肯定会重复。
比如订单表由于数据过多,分到了多个数据库中存储的话,那么这个ID要如何生成呢?
还是以原来的逻辑进行自增的话,那就会出现这种情况: 数据库A里边有订单1、2、3 , 数据库B里边也有个订单1、2、3, 这在业务逻辑上就冲突了。
Read more »
探秘分布式解决方案: 分布式事务——微服务架构下的主流解决方案之TCC
说完了分布式事务最核心的思想(2PC) –> [探秘分布式解决方案: 分布式事务——从核心思想之2PC(两阶段提交)开始] http://skypyb.com/2019/11/jishu/1149/
那么现在进入到更加复杂的场景。像这种跨库调用之类的,一线互联网公司早就不玩这一套东西了。这都9102年了,上来就是微服务架构。
我这么多服务,你整个啥跨库调用呢?一个服务可能同时调用多个其他的服务。这多个其他的服务中都要执行SQL语句,修改落实到服务所对应的数据库之中。
Read more »