将 Kindle 电子书导入 iBooks

将 Kindle 电子书导入 iBooks

Kindle 已经用了好久了，确实极大的提升了我的阅读效率。Kindle 可谓是既实惠又方便，但是也有一些淡淡的忧伤——技术类书籍阅读不方便。 本文中我就通过将 Kindle 的电子书转为 edup 格式，然后导入 iBooks 来缓解这种不方便。（另外本文也可以解决 Amazon 因美区和中区账号不互通导致 Kindle 要来回切换账号的尴尬） 本篇文章，只供个人购买的正版书籍进行参考使用。请

Kindle iBooks DRM Calibre Reading
折腾：在 Hexo 的 page 中嵌入 iframe

折腾：在 Hexo 的 page 中嵌入 iframe

周末没事就把之前的一键给证件照片打水印的那个小工具更新了一下。因为我平时也要用，而自从上次将博客又从 Ghost 迁回 Hexo 后，这些小工具就一直没空迁过来。这周末得空，就把这个给迁移一下，顺便又更新了一下，要不每次自己在 PS 里搞水印总是有种杀鸡用牛刀的感觉。 Hexo 跟 Ghost 的区别还是挺大的（那不废话嘛，一静一动能不大嘛）。在 Ghost 里我能直接在 page 页里写完整 H

Hexo Blog Front-end iframe
Spring Cloud（十六）：Spring Cloud Gateway（续）

Spring Cloud（十六）：Spring Cloud Gateway（续）

本文主要介绍 Spring Cloud Gateway 的路由熔断、路由重试和高可用。 路由熔断在前面学习 Hystrix 的时候，我们知道 Hystrix 有服务降级的能力，即如果服务调用出现了异常，则执行指定的 fallback 方法。Spring Cloud Gateway 也融合了 Hystrix，可以为我们提供路由层面服务降级。我们就来看看如何来做。

Spring Cloud Microservices Hystrix Gateway Filter Spring Cloud Gateway Retry
Spring Cloud（十五）：Spring Cloud Gateway（限流）

Spring Cloud（十五）：Spring Cloud Gateway（限流）

绝境长城（冰与火之歌） 在高并发的应用中，限流是一个绕不开的话题。限流可以保障我们的 API 服务对所有用户的可用性，也可以防止网络攻击。 一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如 nginx 的 limit_conn 模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如 Guava 的 RateLimiter、nginx 的 li

Spring Cloud Microservices Gateway Filter Spring Cloud Gateway Finchley Rate limiting
Spring Cloud（十四）：Spring Cloud Gateway（过滤器）

Spring Cloud（十四）：Spring Cloud Gateway（过滤器）

在上一篇文章中，我们了解了 Spring Cloud Gateway 作为网关所具备的基础功能：路由。本篇我们将关注它的另一个功能：过滤器。 Spring Cloud Gateway 已经内置了很多实用的过滤器，但并不能完全满足我们的需求。本文我们就来实现自定义过滤器。虽然现在 Spring Cloud Gateway 的文档还不完善，但是我们依旧可以照猫画虎来定制自己的过滤器。

Spring Cloud Microservices Gateway Filter Spring Cloud Gateway
Spring Cloud（十三）：Spring Cloud Gateway（路由）
Lombok 与 JDK 10
Log4j2 将不同线程不同级别日志输出到不同的文件中

Log4j2 将不同线程不同级别日志输出到不同的文件中

在多线程编程中，如果不做特殊的设置，那么多个线程的日志会输出到同一个日志文件中，这样在查阅日志的时候，会带来诸多不便。很自然地，我们想到了让不同的线程输出日志到不同的文件中，这样不是更好吗？ 本篇文章我们利用 Log4j2 来将不同线程的不同级别的日志打印到不同的文件中，并使用异步的方式来大大的提高日志输出的性能。

Java Log4j2
MySQL 优化之 Covering Index
MySQL 优化原理（三）

MySQL 优化原理（三）

聊聊 MySQL 配置。 大多数开发者可能不太会关注 MySQL 的配置，毕竟在基本配置没有问题的情况下，把更多的精力放在 schema 设计、索引优化和 SQL 优化上，是非常务实的策略。这时，如果再花力气去优化配置项，获得的收益通常都比较小。更多的时候，基于安全因素的考量，普通开发者很少能够接触到生产环境的 MySQL 配置。正是这样，导致开发者（包括我）对 MySQL 的配置不甚了解，希望本

Performance MySQL
MySQL 优化原理（二）

MySQL 优化原理（二）

如果有同学看完上一篇关于 MySQL 文章，文末留有两个很开放的问题，如有兴趣可以在脑袋里想想。本文也会试着回答这两个问题，希望能给你一些参考。现在可以思考一个问题，如果数据量非常大的情况下，您根据业务选择了合适的字段，精心设计了表和索引，还仔细的检查了所有的 SQL，并确认已经没什么问题，但性能仍然不能满足您的要求，该怎么办呢？还有其他优化策略吗？答案是肯定的。接下来继续和您讨论一些常用的 My

Performance MySQL
MySQL 优化原理（一）

MySQL 优化原理（一）

说起 MySQL 的查询优化，相信大家收藏了一堆奇技淫巧：不能使用SELECT *、不使用 NULL 字段、合理创建索引、为字段选择合适的数据类型……你是否真的理解这些优化技巧？是否理解其背后的工作原理？在实际场景下性能真有提升吗？我想未必。因而理解这些优化建议背后的原理就尤为重要，希望本文能让你重新审视这些优化建议，并在实际业务场景下合理的运用。

Performance MySQL
MySQL 轻松创建千万级测试数据

MySQL 轻松创建千万级测试数据

在进行查询操作的性能测试时，我们往往需要测试大数据量模式下的查询功能的性能，这时就需要我们去创造一些测试数据来填充数据库，来模拟真实环境。制造数据的方式有很多种。可以使用 LoadRunner，JMeter 等压测工具压一些数据进去，但这样做效率不高。也可以用程序生成一个数据文件，再用 load data 加载，这样虽然快了但是又不够灵活。 本文介绍两种快速生成大量测试数据的方法，分别使用存储过程

MySQL
RabbitMQ 安装笔记
Spring Cloud 与响应式微服务
使用 Spring 5 的 Webflux 开发 Reactive 应用
Spring Cloud（十二）：分布式链路跟踪 Sleuth 与 Zipkin【Finchley版】

Spring Cloud（十二）：分布式链路跟踪 Sleuth 与 Zipkin【Finchley版】

随着业务发展，系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，我们是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。 现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed

Spring Cloud Microservices Spring Cloud Sleuth Zipkin
Spring Cloud（十一）：服务网关 Zuul（过滤器）【Finchley 版】

Spring Cloud（十一）：服务网关 Zuul（过滤器）【Finchley 版】

在上篇文章中我们了解了 Spring Cloud Zuul 作为网关所具备的最基本功能：路由（Router）。本文我们将关注 Spring Cloud Zuul 的另一核心功能：过滤器（Filter）。 Filter 的作用我们已经能够实现请求的路由功能，所以我们的微服务应用提供的接口就可以通过统一的 API 网关入口被客户端访问到了。但是，每个客户端用户请求微服务应用提供的接口时，它们的访问权限

Spring Cloud Netflix Microservices Zuul Gateway Filter
Spring Cloud（十）：服务网关 Zuul（路由）【Finchley 版】

Spring Cloud（十）：服务网关 Zuul（路由）【Finchley 版】

通过之前几篇 Spring Cloud 中几个核心组件的介绍，我们已经可以构建一个简略的微服务架构了，可能像下图这样： 我们使用 Spring Cloud Netflix 中的 Eureka 实现了服务注册中心以及服务注册与发现；而服务间通过 Ribbon 或 Feign 实现服务的消费以及均衡负载；通过 Spring Cloud Config 实现了应用多环境的外部化配置以及版本管理。为了使得

Spring Cloud Netflix Microservices Zuul Router Gateway
MyBatis 中 # 与 $ 的区别