如果你问自己是否Apache Kafka比RabbitMQ更好或RabbitMQ是否比Apache Kafka更可靠，我想在这里阻止你。本文将从更广泛的角度讨论这两种情况。它关注的是这两个系统提供的功能，并将指导您做出正确的决定，决定何时使用哪个系统。
web上的一些文章让Apache Kafka在RabbitMQ面前大出风头，而另一些文章则恰恰相反。我们中的很多人可能会因为听了大肆宣传，跟着人群跑而认罪。我觉得重要的是要知道是使用RabbitMQ还是Kafka取决于您项目的需求，只有当您在合适的场景中使用了正确的设置，才能进行真正的比较。
在微服务拆分的架构中，各服务拥有自己的数据库，所以常常会遇到服务之间数据通信的问题。比如，B服务数据库的数据来源于A服务的数据库；A服务的数据有变更操作时，需要同步到B服务中。
第一种解决方案:
在代码逻辑中，有相关A服务数据写操作时，以调用接口的方式，调用B服务接口，B服务再将数据写到新的数据库中。这种方式看似简单，但其实“坑”很多。在A服务代码逻辑中会增加大量这种调用接口同步的代码，增加了项目代码的复杂度，以后会越来越难维护。并且，接口调用的方式并不是一个稳定的方式，没有重试机制，没有同步位置记录，接口调用失败了怎么处理，突然的大量接口调用会产生的问题等，这些都要考虑并且在业务中处理。这里会有不少工作量。想到这里，就将这个方案排除了。
光学字符识别（OCR）是指电子设备（例如扫描仪或数码相机）检查纸上打印的字符，通过检测暗、亮的模式确定其形状，然后用字符识别方法将形状翻译成计算机文字的过程。百度自己的开源产品是PaddleOCR，总模型大小仅8.6M。
PaddleOCR旨在打造一套丰富、领先、且实用的OCR工具库，助力使用者训练出更好的模型，支持iOS和Android系统，功能如此齐全，难怪霸榜Github热榜：
Spring Boot工程自带logback和slf4j的依赖，所以重点放在编写配置文件上，需要引入什么依赖，日志依赖冲突统统都不需要我们管了。
logback框架会默认加载classpath下命名为logback-spring或logback的配置文件。
将所有日志都存储在一个文件中文件大小也随着应用的运行越来越大并且不好排查问题，正确的做法应该是将error日志和其他日志分开，并且不同级别的日志根据时间段进行记录存储。
了解 Kafka 的内部工作原理有助于理解 Kafka 的行为，也利用快速诊断问题。下面我们来探讨一下这三个问题
我们知道，Kafka 是运行在 ZooKeeper 之上的，因为 ZooKeeper 是以集群形式出现的，所以 Kafka 也可以以集群形式出现。这也就涉及到多个生产者和多个消费者如何协调的问题，这个维护集群间的关系也是由 ZooKeeper 来完成的。如果你看过我之前的文章(真的，关于 Kafka 入门看这一篇就够了)，你应该会知道，Kafka 集群间会有多个 主机(broker)，每个 broker 都会有一个 broker.id，每个 broker.id 都有一个唯一的标识符用来区分，这个标识符可以在配置文件里手动指定，也可以自动生成。
我们在讨论分布式系统的时候，曾经谈过分布式系统要解决的是高并发、大数量和快速响应的问题。事实上，在互联网中，大部分的业务还是以查询数据为主，而非更改数据为主。在互联网出现高并发的时刻，查询关系数据库，会造成关系数据库的压力增大，容易导致系统宕机的严重后果。为了解决这个问题，一些开发者提出了数据缓存技术，数据缓存和关系数据库最大的不同在于，缓存的数据是保存在计算机内存上的，而关系数据库的数据主要保存在磁盘上。计算机检索内存的速度是远超过检索磁盘的，所以缓存技术可以在很大程度上提高整个系统的性能，降低数据库的压力。
使用缓存技术最大的问题是数据的一致性问题，缓存中存储的数据是关系数据库中数据的副本，因为缓存机制与数据库机制不同，所以它们的数据未必是同步的。虽然我们可以使用弱一致性去同步数据，但是现实很少会那么做，因为在互联网系统中，往往查询是可以允许部分数据不实时的，甚至是失真的，例如，一件商品的真实库存是100件，而现在显示是99件，这并不会妨碍用户继续购买。如果使用弱一致性，一方面会造成性能损失，另外一方面也会造成开发者工作量的大量增加。
Apache Ignite为开发人员提供了实时处理大数据和内存计算的方便易用的解决方案。主要有以下几点功能：
Apache Ignite核心技术特点如下：
ThreadLocal是JDK默认提供的本地线程变量，用来存储在整个调用链中都需要访问的数据，并且是线程安全的。由于本文的写作背景是笔者需要在公司落地全链路跟踪平台，一个基本并核心的功能需求是用户的每个操作动作需要在整个调用链中进行埋点传递，线程上下文环境成为解决这个问题最合适的技术。
ThreadLocal是在Thread类之外实现的一个功能（java.lang.ThreadLocal）， 但它会为每个线程分别存储一份唯一的数据。正如它的名字所说的，它为线程提供了本地存储，也就是说你所创建出来变量对每个线程实例来说都是唯一的。和线程 名，线程优先级类似，你可以自定义出一些属性，就好像它们是存储在Thread线程内部一样。
RPC 框架的目标就是让远程服务调用更加简单、透明，RPC 框架负责屏蔽底层的传输方式（TCP 或者 UDP）、序列化方式（XML/Json/ 二进制）和通信细节。服务调用者可以像调用本地接口一样调用远程的服务提供者，而不需要关心底层通信细节和调用过程。
常言道，温故而知新。
我们先看官网上是怎么解释的：
从上文中，我们可以得出以下几点结论：
想要深入学习nginx，阅读源码一定是非常重要的一环，但nginx源码量毕竟还是不算少，一不小心就容易陷入某个细节，迷失在茫茫码海之中。
如果有一张地图，让我们开启上帝视角，总览全局，帮助我们快速学习整体框架结构，又能不至于迷失其中那就再好不过了！
大多数ElasticSearch用户在创建索引时通用会问的一个重要问题是：我需要创建多少个分片?
分片分配是个很重要的概念, 很多用户对如何分片都有所疑惑, 当然是为了让分配更合理. 在生产环境中, 随着数据集的增长, 不合理的分配策略可能会给系统的扩展带来严重的问题。
同时这方面的文档介绍也非常少，很多用户只想要明确的答案而不仅仅一个数字范围，甚至都不关心随意的设置可能带来的问题。
如果你刚接触ElasticSearch，那么弄清楚它的几个术语和核心概念是非常必要的。
工作中业务场景非常多，所涉及到的场景也各不相同，这使得我们定时任务系统应该集管理、调度、任务分配、监控预警为一体的综合调度系统,如何打造一套健壮的、适应不同场景的系统，技术选型尤其重要。
针对以上场景我们需要我们的分布式任务系统具备以下能力：
- 支持多种作业类型(shell作业/Java作业)
- 支持作业HA，负载均衡和失败转移
- 支持弹性扩容(应对开门红以及促销活动)
- 支持Job Timeout 处理
- 支持统一监控和告警
- 支持作业统一配置
- 支持资源隔离和作业隔离
工作流调度：一个完整的数据分析系统通常都是由大量任务单元组成：shell脚本程序，java程序，mapreduce程序、hive脚本等，各任务单元之间存在时间先后及前后依赖关系。为了很好地组织起这样的复杂执行计划，需要一个工作流调度系统来调度执行。
调度工具性能对比：Apache Oozie，其配置工作流的过程是编写大量的XML配置，而且代码复杂度比较高，不易于二次开发。ooize相比azkaban是一个重量级的任务调度系统，功能全面，但配置使用也更复杂。如果可以不在意某些功能的缺失，轻量级调度器azkaban是很不错的候选对象。
Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。使用Shiro的易于理解的API,您可以快速、轻松地获得任何应用程序,从最小的移动应用程序到最大的网络和企业应用程序。
三个核心组件：Subject, SecurityManager 和 Realms.
从这个意义上讲，Realm实质上是一个安全相关的DAO：它封装了数据源的连接细节，并在需要时将相关数据提供给Shiro。当配置Shiro时，你必须至少指定一个Realm，用于认证和（或）授权。配置多个Realm是可以的，但是至少需要一个。
最近在做订单模块，用户购买服务类产品之后，需要进行预约，预约成功之后分别给商家和用户发送提醒短信。考虑发短信耗时的情况所以我想用异步的方法去执行，于是就在网上看见了Spring的@Async了。
但是遇到了许多问题，使得@Async无效，也一直没有找到很好的文章去详细的说明@Async的正确及错误的使用方法及需要注意的地方，这里简单整理了一下遇见的问题，Sring是以配置文件的形式来开启@Async，而SpringBoot则是以注解的方式开启。
我们可以使用springBoot默认的线程池，不过一般我们会自定义线程池（因为比较灵活），配置方式有：
下面分别实现两种配置方式
数据网格是一组能够提供共享数据管理的服务，它可以通过网格状的结构，去访问源自各种应用程序与服务的异构数据。
在技术实现上，我们通常可以采用功能强大的中间件应用程序和服务，实现对于源于各种应用请求的数据输入与查询。
网格中的数据往往可以通过诸如 REST、以及 JSON 格式的 API 被访问到。这些数据既可以被保存到磁盘上，也能够备份到另一个数据库里。
反应式编程来源于数据流和变化的传播，意味着由底层的执行模型负责通过数据流来自动传播变化。比如求值一个简单的表达式 c=a+b，当 a 或者 b 的值发生变化时，传统的编程范式需要对 a+b 进行重新计算来得到 c 的值。如果使用反应式编程，当 a 或者 b 的值发生变化时，c 的值会自动更新。反应式编程最早由 .NET 平台上的 Reactive Extensions (Rx) 库来实现。后来迁移到 Java 平台之后就产生了著名的 RxJava 库，并产生了很多其他编程语言上的对应实现。在这些实现的基础上产生了后来的反应式流（Reactive Streams）规范。该规范定义了反应式流的相关接口，并将集成到 Java 9 中。
在传统的编程范式中，我们一般通过迭代器（Iterator）模式来遍历一个序列。这种遍历方式是由调用者来控制节奏的，采用的是拉的方式。每次由调用者通过 next()方法来获取序列中的下一个值。使用反应式流时采用的则是推的方式，即常见的发布者-订阅者模式。当发布者有新的数据产生时，这些数据会被推送到订阅者来进行处理。在反应式流上可以添加各种不同的操作来对数据进行处理，形成数据处理链。这个以声明式的方式添加的处理链只在订阅者进行订阅操作时才会真正执行。
Apollo（阿波罗）[参考附录] 是携程框架部研发并开源的一款生产级的配置中心产品，它能够集中管理应用在不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
Apollo 目前在国内开发者社区比较热，在 Github 上有超过 5k 颗星，在国内众多互联网公司有落地案例，可以说 Apollo 是目前配置中心产品领域 Number1 的产品，其成熟度和企业级特性要远远强于 Spring Cloud 体系中的 Spring Cloud Config 产品。
对于高性能的 RPC 框架，Netty 作为异步通信框架，几乎成为必备品。例如，Dubbo 框架中通信组件，还有 RocketMQ 中生产者和消费者的通信，都使用了 Netty。今天，我们来看看 Netty 的基本架构和原理。
Netty 是一个异步的、基于事件驱动的网络应用框架，它可以用来开发高性能服务端和客户端。
以前编写网络调用程序的时候，我们都会在客户端创建一个 Socket，通过这个 Socket 连接到服务端。
服务端根据这个 Socket 创建一个 Thread，用来发出请求。客户端在发起调用以后，需要等待服务端处理完成，才能继续后面的操作。这样线程会出现等待的状态。
如果客户端请求数越多，服务端创建的处理线程也会越多，JVM 如此多的线程并不是一件容易的事。
使用阻赛 I/O 处理多个连接
在高并发的分布式的系统中，缓存是必不可少的一部分。没有缓存对系统的加速和阻挡大量的请求直接落到系统的底层，系统是很难撑住高并发的冲击，所以分布式系统中缓存的设计是很重要的一环。下面就来聊聊分布式系统中关于缓存的设计以及过程中遇到的一些问题。
使用缓存我们得到以下收益：
当代的互联网的服务，通常都是用复杂的、大规模分布式集群来实现的。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具。
Dapper–Google生产环境下的分布式跟踪系统，应运而生。那么我们就来介绍一个大规模集群的跟踪系统，它是如何满足一个低损耗、应用透明的、大范围部署这三个需求的。当然Dapper设计之初，参考了一些其他分布式系统的理念，尤其是Magpie和X-Trace，但是我们之所以能成功应用在生产环境上，还需要一些画龙点睛之笔，例如采样率的使用以及把代码植入限制在一小部分公共库的改造上。
周末无聊刷着手机，某宝网APP突然蹦出来一条消息“为了回馈老客户，女朋友买一送一，活动仅限今天！”。买一送一还有这种好事，那我可不能错过！忍不住立马点了去。于是选了两个最新款，下单、支付一气呵成！满足的躺在床上，想着马上有女朋友了，竟然幸福的失眠了……
第二天正常上着班，突然接到快递小哥的电话：
小哥：“你是xx吗？你的女朋友到了，我现在在你楼下，你来拿一下吧！”。
我：“这……我在上班呢，可以晚上送过来吗？“。
小哥：“晚上可不行哦，晚上我也下班了呢！”。
于是两个人僵持了很久……
最后小哥说，要不我帮你放到楼下小芳便利店吧，你晚上下班了过来拿，尴尬的局面这才得以缓解！
几十年前，消息队列开始兴起，它用于连接大型机和服务器应用程序，并逐渐在企业的服务总线与事件总线设计模式、应用间的路由和数据迁移中发挥至关重要的作用。自此，应用程序架构和数据角色经历了重大变化：例如，面向服务的架构、流处理、微服务、容器化、云服务和边缘计算，这些只是诸多变化中的冰山一角。这些变化创造了大量的新需求，这些新需求远远超出了原有消息队列的技术能力。
为了满足这些需求，处理消息队列的全新方法应运而生。现代应用对消息解决方案的要求不仅仅是主动连接、移动数据，而是要在持续增长的服务和应用中智能处理、分析和传输数据，并且在规模持续扩大的情况下不增加运营负担。