今年进入我工作的第四个年头, 三年多的时间里, 算上实习, 经历过3家公司. 见过了各种各样的同事, 也算见过各式各样的代码. 这篇文章主要是想分享一下一个java后端三年的一些感悟

重复学习了很多年 从事前端开发已经超过5年，自诩也是一个坚持学习的程序猿。 今年工作不是很忙，并且职场的35岁槛已经到来，既有时间又有压力，于是更多的时间在思考成长这件事。 最近在做的一件特别重要

一个接口可能需要调用 N 个其他服务的接口，这在项目开发中还是挺常见的。举个例子：用户请求获取订单信息，可能需要调用用户信息、商品详情、物流信息、商品推荐等接口，最后再汇总数据统一返回。 如果是串行（

假设系统中有一个接口，这个接口已经被10个实现类实现了，突然有一天，新的需求来了，其中5个实现类需要实现同一个方法。然后你就在接口中添加了这个方法的定义，想着一切都很完美。 当你在接口和其中5个实现类

今天咱们来看一道数据库中比较经典的面试问题：为什么要使用雪花 ID 替代数据库自增 ID？同时这道题也出现在了浩鲸科技的 Java 面试中，下面我们一起来看吧。 浩鲸科技的面试题如下： 其他面试题相对

由于简历上，写了分库分表，还写了精通微服务和分布式系统，然后被面试官一顿蹂躏了这里面的技术细节；尤其给我印象最深的问题是，在分布式环境下，你们数据的唯一ID是如何去生成的？ 当时条件反射，无脑的回答到

Git是一款分布式版本控制系统，广泛应用于软件开发中。它可以帮助团队协作开发，追踪代码变更，回滚错误提交等。将我们的项目与远程仓库（如GitHub、GitLab等）连接起来，以便协作和备份。

我们在浏览网站后台的时候，假如我们频繁请求，那么网站会提示 “请勿重复提交” 的字样，那么这个功能究竟有什么用呢，又是如何实现的呢？ 其实这就是接口防刷的一种处理方式，通过

MQ的作用解耦、异步、削峰填谷。 未使用MQ的情况 mysql并发写大部分情况下维持在600-800之间，并发读1200-1500之间，所以消费端在消费消息的时候需控制在并发小于1000，从而达到限流