上周产品经理提了一个类似于 LBS 的应用，第一时间想到了忘记了之前什么时候看 Redis 的 API，发现 Redis 自 3.2 版本之后，新增了一类关于地理位置相关的 API，于是拿来测试一下，发现特别好用，写一个小例子作为笔记。
首先需要说明的是，由于我们公司的 JDK 的版本是 1.7，所以我采用的 spring-data-redis 的版本是：1.8.20.RELEASE，最新二点几的版本已经不支持 JDK 1.7，而一点几和二点几的版本的 API 有略微的差异（下面会说明，还有一点点我的小感悟），废话不多说，直接看例子：
@Override[......]
前几天同事分享了一些关于 Guava 的一起基础用法，我之前没用过，感觉挺好的，所以记一些常见的方法。
一. 基础工具类，字符串相关的
其实这些在 apache commons-lang3，算是重复造轮子吧，简单说一下。
1. 判断字符串是否为空，之前看到很多人自己定义，这些可能是一些老程序员吧，apache commons-lang3，Guava 的如下：
boolean nullOrEmpty = Strings.isNullOrEmpty("");
2. 补全字符串(在前面补全和后面补全)
[......]
一、CAP 理论
CAP 理论是分布式计算领域公认的一个定理，是分布式架构师必须掌握的理论，目前网上关于这块的资料也很多，各种说法，其实 CAP 理论自身也是一个不断发展的过程，相比之下比较准确的说法应该是：在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。也就是说必须是相关连接并且共享数据的分布式系统才是我们讨论 CAP 的基础，另外就是 CAP 理论关注的是对数据的读写操作，而不是分布式系统的所有功[……]
这个问题其实不能称之为问题，给服务器命名应该算是一个常识性问题，任何人都可以想到的，其实不仅是服务器，在我们生活中的一切都有名字，如果我们生活在一个没有名字的世界中，你想想有多可怕把？但为什么写这篇文章呢？因为我们公司很奇怪，不知道是运维疏忽还是啥，每次通过跳板机登陆线上服务器，必须通过 IP 地址才行，所以每个人一定要记录自己负责的服务器的 IP 地址才可以，否则一筹莫展，但是 IP 地址，大家都懂得，不然也不会有域名的存在了，大家都通过 IP 访问互联网就好了，前几天看公众号，刚好看到知书堂有位老师写过一篇文章来说这个问题，所以转载过来，供大家给服务器命名参考，后续也会给出我自己的小建议。[……]
前两天在写一个东西的时候，测试的同学说发现一个问题，排序分页，第二页和第一页有重复数据，当时我看了一下，确实有这个问题，然后就想到几年前我就曾经遇到过这个问题，淘宝数据库内核月报上也做了说明，所以这个时候就体现出了老程序员的价值：踩过的坑多，坑坑相连也就都成了平地，考虑到很多人不知道这个问题，所以把原文转载过来，以期能够让更多的人看到，原文如下：
1. 背景
6.5 号，小编在 Aliyun 的论坛中发现一位开发者提的一个问题，说 RDS 发现了一个超级大 BUG，吓的小编一身冷汗 = =!! 赶紧来看看，背景是一个 RDS 用户创建了一张表，在一个都是 NULL 值的非索引字段上[……]
前几天在项目中遇到一个小问题，有一个 Excel 文件放在 classpath 下，通过流下载下来，本地测试的时候一点问题都没，但是部署到测试环境却不行了，说文件已损坏，然后打不开，简单代码如下：
@RequestMapping(value = "/export", method = RequestMethod.GET)
public void export(HttpServletResponse response) {
ServletOutputStream servletOutputStream = null;[......]
前几天刷微博，看到博主 @Java大本营 发了一个图片，总结 Java 一些常见的知识点，感觉挺好，整理成文字版，发在我的个人博客，作为一个大家学习复习的文档，也欢迎有人在评论中留下各种参考资料，一下是正文。
一、基础篇
1. JVM
①. JVM 内存结构
堆、栈、方法区、直接内存、堆和栈的区别
②. Java 内存模型
内存可见性、重排序、顺序一致性、volatile、锁、final
③. 垃圾回收
内存分配策略、垃圾收集器(G1)、GC 算法、GC 参数、对象存活的判定
④. JVM 参数及调优
⑤. Java 对象模型
oop-klass、对象[……]
说实话，由于我个人某些基础不是很牢固，所以前一段时间关于 Spring Aop 踩了一个坑，其实很简单，今天就记录一下，先说结论：
不能被 Spring AOP 增强的方法：
1. 基于接口的动态代理：除 public 外的其它所有的方法，此外 public static 也不能被增强
2. 基于 CGLib 的动态代理：private、static、final 的方法，也就是只有 public 和 protected 可以，但是要注意切入点语法的配置
测试用例如下，pom 文件：
<dependency>[......]
按：系统架构经过多年演进，现在越来越多的系统采用微服务架构，而说到微服务架构必然牵涉到分布式，以前单体应用加锁是很简单的，但现在分布式系统下加锁就比较难了，我之前曾简单写过一篇文章，关于分布式锁的实现，但有一次发现实现的分布式锁是有问题的，因为出问题的概率很低，所以当时也没在意，前几天和朋友聊这个问题，想起来看过一篇文章，写的不错，今天特转载过来，希望能让更多的人看到，同时也加深一下记忆。原文链接是：http://tech.dianwoda.com/2018/04/11/redisfen-bu-shi-suo-jin-hua-shi/
以下为原文：
近两年来微服务变得越来越热门，越[……]
按：系统架构经过多年演进，现在越来越多的系统采用微服务架构，而微服务架构最重要的就是面向接口编程，所以接口的设计就尤为重要了，我一直认为一个好的接口自己会说话，也就是看到接口，我就知道这个接口是干啥的、参数是啥、返回值是啥以及可能会遇到哪些问题，但目前对 RPC 接口设计可以说有两派，前一段时间看了一篇文章是我的想法完全一样，特转载到本人博客，希望更多的能够看到、有更多的人参与讨论两种的优劣。
在开始之前呢，先吐槽一个本文没有提到的问题，我不知道有些人是怎么想的，对外暴露的接口，也就是最终被打成 jar 包供外部服务依赖模块，有些人喜欢在里面引入各种无关的第三方依赖，我遇到过把 spri[……]
近期评论