本片笔记主要是记录我整合Dubbo的过程。引入Dubbo主要是为了实现微服务之间的调用，即：RPC（Remote-Process-Call，远程过程调用）。本次整合Dubbo可谓是曲折坎坷，耗费了不少时间和精力。不过也是收获挺多的，有些项目问题，真的不亲身经历，终是【纸上谈兵】。举个鲜明的例子：我为什么要自己从0开始搭建微服务项目？因为我想要获得【从0开始搭建项目】的经验和能力！maven的基本知

前面我们介绍过了Redis主从哨兵的方案。在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在【访问瞬断】的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存

点击idea启动的时候没反应，接着百度报错，基本跟他们的也不一样。首先我是做版本升级。其次，我之前是破解的。如果你也是跟我一样的话，那问题可能就处在破解上了。

RT详细的报错内容如下：Error:Maven Resources Compiler: Failed to copy 'F:\code\new\ifood-alliance-platform\src\main\resources\application-business.yml' to 'F:\code\new\ifood-alliance-platform\target\classes\appl

Redis中间件，非常推荐大家学的一个东西。甚至这么说，Redis也许是我们Java程序员，能接触到的分布式、微服务中间件中一个较为高级，但又比较接地气的中间件了。为什么接地气？因为哪怕是在小项目中，Redis都是一个比较常用、可靠的中间件！但是我发现，新手用Redis缓存很容易钻入一个牛角尖，那就是Redis会不会崩啊？万一哪一天断电了，宕机了呢？最后得到一个结论：Redis不可靠啊！！！但现实

最近在线上遇到一个很难受的BUG，我一度以为是我代码逻辑出了问题，用了Arthas定位分析之后，开始坚定了信心：大概率是POI的API有问题，比如写入数据过多。PS：上图为正常的下拉框。但是，当下拉选项过多时（跟多少无关，而是跟字节数有关），会导致下拉框内容显示失败。

RT详细的报错内容如下：Error:Maven Resources Compiler: Failed to copy 'F:\code\new\ifood-alliance-platform\src\main\resources\application-business.yml' to 'F:\code\new\ifood-alliance-platform\target\classes\appl

存储过程是一组为了完成特定功能的 SQL 语句集合。使用存储过程的目的是将常用或复杂的工作预先用 SQL 语句写好并用一个指定名称存储起来，这个过程经编译和优化后存储在数据库服务器中，因此称为存储过程。当以后需要数据库提供与已定义好的存储过程的功能相同的服务时，只需调用“CALL存储过程名字”即可自动完成。（对应的就是Java里面的函数）

语法结构比较陌生没有中文文档， 只能看英文其他博客也比较少介绍语法结构。比如说，为什么查询中会出现query关键词就跟Mysql有自己的查询语言一样，ES作为一款优秀的分布式文档存储和【搜索引擎】，它也有自己的查询语言。即：Query DSL（查询Domain Specific Language），查询领域专用语言。Query DSL是利用RESTfull风格API传递JSON格式的请求体（Req

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。比如：在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保