有如下两个服务（或多个服务），各服务通过Redis做Session共享以实现单点登录。其中登录走的是API服务，前端通过Cookie来维持登录状态。在API服务登录之后，在所有服务中这个用户（Token）都是登录是登录状态的。

1
2
3

WEB：https://web.guitu18.com
API：https://api.guitu18.com
... // 其他服务

因为登录走的是API服务，那么Cookie的作用域是api.guitu18.com，这时候访问WEB项目，WEB后台虽然知道这个用户（token）是登录的，但因为请求是从web.guitu18.com域发起的，WEB服务是无法获取api.guitu18.com域下的Cookie的。

SSH登录方式

接触过Linux服务器的同学肯定用过SSH协议登录系统，通常SSH协议都有两种登录方式：密码口令登录和公钥登陆。

一、密码口令（类似于账号密码登录）

1.客户端连接服务器，服务器把公钥发给客户端
2.客户端输入登录口令，并用服务器公钥加密后提交给服务器
3.服务器用私钥解密，结果匹配，则允许登录

二、公钥登录（一般用RSA非对称加密）

1.客户端生成密钥对
2.将客户端的公钥写入服务器的密钥验证文件
3.客户端请求登录，服务器生成一段随机字符串，并使用客户端公钥加密后发送给客户端
5.客户端使用自己的私钥解密，并返回解密后的信息到服务器
6.服务器进行信息对比，如果结果匹配，则允许登录

MongoDB和MySQL的一些常用的查询语句对比，MongoDB的一些语法及其查询示例。

最近有线上朋友私信问我怎么搭建个人博客，也有咨询我个人项目的代码是如何保管的，还有一个朋友问我买了服务器玩了一段时间，等新鲜感过了就不知道做什么了。

关于这些问题并没有一个标准答案，每个人都有自己的使用习惯，找到适合你的才是最好的。关于博客搭建及使用的工具或服务在我博客的关于页里已经写的比较详细了，如果有人想看具体步骤我可以专门写一篇详细的教程，本篇先来讲讲我的个人项目代码是如何保管的。

关于Docker的官方介绍网上太多了我就不贴了，就实际体验来说Docker可以极大的简化环境搭建及服务部署的操作流程，大大降低部署的时间成本，解放你的双手。

本文不会深入讲解Docker底层架构及运行原理，也不会有一堆架构图贴在这里。该篇旨在让你以最快的速度学会使用Docker，关于Docker的架构及其底层的一些知识，你可以在学会Docker的基本使用之后再去了解。开门见山讲架构聊底层有点容易让人犯迷糊，但在使用Docker之前你至少应该了解他的三大核心组件：仓库、镜像和容器，以及他们之前的关系。本文将通过一个MySQL示例带你了解并使用Docker，待你对Docker有一个基本了解后你再回头去看他的体系架构会容易理解。

明确需求

在使用Shiro的时候，鉴权失败一般都是返回一个错误页或者登录页给前端，特别是后台系统，这种模式用的特别多。但是现在的项目越来越多的趋向于使用前后端分离的方式开发，这时候就需要响应Json数据给前端了，前端再根据状态码做相应的操作。那么Shiro框架能不能在鉴权失败的时候直接返回Json数据呢？答案当然是可以。

其实Shiro的自定义过滤器功能特别强大，可以实现很多实用的功能，向前端返回Json数据自然不在话下。通常我们没有去关注它是因为Shiro内置的一下过滤器功能已经比较全了，后台系统的权限控制基本上只需要使用Shiro内置的一些过滤器就能实现了，此处再次贴上这个图。

相关文档地址：http://shiro.apache.org/web.html#default-filters

我最近的一个项目是需要为手机APP提供功能接口，需要做用户登录，Session持久化以及Session共享，但不需要细粒度的权限控制。面对这个需求我第一个想到的就是集成Shiro了，Session的持久化及共享在Shiro系列第二篇已经讲过了，那么这篇顺便用一下Shiro中的自定义过滤器。因为不需要提供细粒度权限控制，只需要做登录鉴权，而且鉴权失败后需要向前端响应Json数据，那么使用自定义Filter再好不过了。

写这篇是因为最近将博客从服务器迁移到虚拟主机上了，我需要在Linux服务器上将我的Hexo博客编译后的静态页面上传至虚拟主机上，我的虚拟主机上传文件有且仅有一种方式：FTP。

先说下我想实现的自动部署流程，我在Jenkins上做了监听，一旦我的Hexo代码仓库有新的提交，会触发任务脚本执行发布操作。具体要做的事都写在Shell脚本上，主要流程如下：

1. 脚本配置，配置Hexo工作目录，静态文件上传目录，FTP配置信息等；
2. 进入Hexo工作目录，更新代码，清除缓存，编译生成静态页面；
3. 递归读取Hexo静态页面目录，上传博客静态页文件到FTP空间对应的目录；
4. 执行Hexo deploy命令，发布静态页面，我这里配置的是发布到Github；

流程大概就是这样，Shell脚本好说，FTP工具命令是踩了不少坑。说实话这FTP工具很不友好，一些常用的功能不支持，比如不能一次创建多级目录，只能一级一级逐层创建。

数据库优化是一个任重而道远的任务，想要做优化必须深入理解数据库的各种特性。在开发过程中我们经常会遇到一些原因很简单但造成的后果却很严重的疑难杂症，这类问题往往还不容易定位，排查费时费力最后发现是一个很小的疏忽造成的，又或者是因为不了解某个技术特性产生的。

于数据库层面，最常见的恐怕就是索引失效了，且一开始因为数据量小还不易被发现。但随着业务的拓展数据量的提升，性能问题慢慢的就体现出来了，处理不及时还很容易造成雪球效应，最终导致数据库卡死甚至瘫痪。造成索引失效的原因可能有很多种，相关技术博客已经有太多了，今天我要记录的是隐式转换造成的索引失效。

数据准备

首先使用存储过程生成1000万条测试数据，
测试表一共建立了7个字段（包括主键），num1和num2保存的是和ID一样的顺序数字，其中num2是字符串类型。
type1和type2保存的都是主键对5的取模，目的是模拟实际应用中常用类似type类型的数据，但是type2是没有建立索引的。
str1和str2都是保存了一个20位长度的随机字符串，str1不能为NULL，str2允许为NULL，相应的生成测试数据的时候我也会在str2字段生产少量NULL值（每100条数据产生一个NULL值）。

昨天遇到一个非常奇怪的问题，在一个Service中使用@Transactional注解的一个方法无论如何都不能开启事务。项目用的是Springboot和Mybatis Plus，权限验证用的是Shiro。Service层的伪代码如下：

1
2
3
4
5
6
7
8
9

@Transactional(rollbackFor = Exception.class)
public void register(String username, String password) {
    Member member = new Member();
    ... ...
    this.save(member);
    MemberMessage memberMessage = new MemberMessage();
    ... ...
    memberMessageService.save(memberMessage);
}

当memberMessage插入失败抛异常时，前面保存的member记录不会回滚。打断点发现，只要save(member)这行走完数据就直接插入，此时方法还没执行完，按道理事务应该还没提交，但是通过Navicat已经能够看到新增的记录了。怀疑是事务压根没开启，遂将logging.level.root日志等级改为DEBUG发现压根就没开启事务。

最近突然想整理一下我近十年来保存的资料（大部分是照片），然后就开始百度长期保存数据的最优解决方案，接着就在知乎看到这么一个主题：如何长时间保存重要数据？

先看到了最热门的一个回答，各种技术分析。完了我就想，最近是要多买个硬盘给我的资料做一下整理和备份了，防止发生意外数据丢失。
这个主题有很多知友参与解答，有通过各种专业知识进行分析的，也有抖机灵的，有一位知友引用《三体》的原文：

现代的量子存储器，就是那种一粒米大小可以放下一个大型图书馆的东西，里面的信息最多只能保存两千年左右，两千年后因为内部的什么衰变就不能读取了。其实这还是说那些质量最好的存储器，根据研究，现有的普通量子存储器，有三分之二在五百年内就会坏。

要论信息保存的时间，咱们那个时候的存储器还好些，他们找了些公元世纪的U盘和硬盘，有些居然还能读出来。据实验，这些存储器如果质量好，可以把信息保存五千年左右；特别是我们那时的光盘，如果用特殊金属材料制造，能可靠地保存信息十万年。但这些都不如印刷品，质量好的印刷品，用特殊的合成纸张和油墨，二十万年后仍能阅读。但这就到头了，就是说，我们通常用来存储信息的手段，最多只能把信息可靠地保存二十万年。

史前古陶器上的图案，保存了一万年左右；欧洲岩洞里发现的壁画，大约有四万年的历史；人类的人猿祖先为制造工具在石头上砸出的刻痕，如果也算信息的话，最早在上新世中期出现，距今约二百五十万年。可你别说，还真的找到了一亿年前留下来的信息，当然不是人类留下的，是恐龙的脚印。

“把字刻在石头上，可以保存一亿年。”

没错，信息保存时间最长的方式居然是最原始的石刻。但这些当然跟我现在想做的资料备份无关，我的数据最多也就保存到我这辈子结束为止。哪怕我儿子想怀念我，他会继续保存我留下来的资料作纪念，那我孙子呢，甚至子子孙孙呢，他们甚至在现实中都没见过我，又哪里会对我视若珍宝的资料感兴趣。是啊，那些记得你的人，爱你的人，跟你一起生活过的人，随着他们一个个都离开，我们就真正的从这个世界消失了，永远。。。