瞎比比 大家好，我是艿艿。 花了小半年，肝了一个管理后台快速开发开源项目，嘿嘿。 项目地址是： Github：https://github.com/YunaiV/ruoyi-vue-pro Gitee

今天总监很生气，原因是强调了很多年的缓存同步方案，硬是有人不按常理出牌，挑战权威。最终出了问题，这让总监很没面子。 "一群人拿着大老板的账号在哪里瞎JB测，结果把数据搞出问题来了吧"，总监牛鼻子里喷着

前言 在日常开发中，当项目上线之后，甲方必定会让你提供一堆的验收文档，其中就包括了数据库字典，记得我之前是几十张表，一顿CV大法，一边写一遍骂，这种事情怎么交给我这个开发来做呢，各种吐槽，几个小时过后

简介 为了简化空指针异常判断的代码书写 正常情况下 为了简化书写并适应Lambda表达式 遂引入Optional类 细节就不扣了，直接上手 源码不能丢 要素察觉 实例化Optional的方法 empt

数据的校验的重要性就不用说了，即使在前端对数据进行校验的情况下，我们还是要对传入后端的数据再进行一遍校验，避免用户绕过浏览器直接通过一些 HTTP 工具直接向后端请求一些违法数据。 最普通的做法就像下

微信于今日宣布 《服务号模板消息能力调整》，原先的模板消息能力将于 2021 年 4 月 30 日 24:00 下线，届时将无法使用此接口发送模板消息。 简单来讲，向小程序开发看齐，不能直接通过公众号向已订阅的用户推送模板消息。例如：改版后即使订阅了 招商银行信用卡中心，也无法…

在实际项目中，我们在与其他第三方业务接口进行交互时，可能会因为一些网络波动导致超时失败，但是并不能只一次失败就判定接口请求失败，应该考虑重试多次后如果仍然失败，才返回请求失败。那么应该如何实现呢？

服务雪崩怎么处理？冷接口如何防止资源浪费？。同样的也进入的不维护阶段。不维护不代表被淘汰。只能说明推陈出新。在hystrix基础上我们的服务会更加的健康

大家好，我是小菜，一个渴望在互联网行业做到蔡不菜的小菜。可柔可刚，点赞则柔，白嫖则刚！ Kafka 起初是由 Linkedin 公司采用 Scala 语言开发的一个多分区、多副本且基于 ZooKeeper协调的分布式消息系统，现己被捐献给 Apache 基金会 。 目前 Kaf…