在自然语言处理中，我们经常思考，怎么样才能做好自然语言的理解工作。对我们人类来说，理解某一个自然语言的文本信息，通常都是通过当前的信息，关联自己大脑中存储的关联信息，最终理解信息。例如“他不喜欢吃苹果，但是喜欢吃冰淇淋”，人在理解的时候关联出大脑中的认知信息：苹果，甜的，口感有点脆；冰淇淋，比苹果甜，口感软糯、冰凉，夏天能解暑；小孩更喜欢吃甜食和冰淇淋。所以结合这样的知识，会推理出更喜欢冰淇淋的若干原因。但是现在很多自然语言理解的工作还是聚焦在信息的层面，现在的理解工作类似于一个贝叶斯概率，从已知的训练文本中寻找符合条件的最大化文本信息。
在自然语言处理中做到像人一样去理解文本是自然语言处理的终极目标，所以现在越来越多的研究上，引入了一些额外的知识，帮助机器做好自然语言文本的理解工作。单纯的文本信息只是外部客观事实的表述，知识则是在文本信息基础之上对外部客观事实的归纳和总结，所以在自然语言处理中加入辅助的知识信息，让自然语言理解的更好。
作为重要的业务支柱，我们在选择使用Web开发技术时，往往需要考虑待选技术在各个方面的优缺点。目前，无论是创业公司、还是独立软件提供商(ISV)，普遍都会从AngularJS、React JS、以及Vue.js三个常用技术中进行挑选，毕竟它们都有着优秀的社区支持。为了进一步让您全面了解这三者之间的区别与优缺点，下面我将详细为您介绍与比较AngularJS、React JS和Vue.js。
根据如下图给出的谷歌(Google)趋势分析结果，Vue.js的市场占有份额最高，React JS次之，AngularJS最少。当然，这只能说明三者的普及与使用程度，而并不能直接体现到底哪一种技术绝对优秀。下面让我们进一步来讨论他们在技术应用上的不同特点
前2篇介绍了 agent 如何去修改我们的业务代码，以及如何去收集、发送 trace 数据，但是agent的作用不仅如此，那么他还对我们的代码做了一些什么事情，会对我们的程序造成什么样的性能影响，本文将为你揭晓。
方法 SkyWalkingAgent#premain 之前讲解过这是 agent 的入口方法，这个方法的 前半部分都是在 加载配置文件、加载插件以及拦截了类加载器以便后面去修改字节码，在此之外agent还有最后一个步骤，就是去加载所有BootService接口的实现类。
阅读更多
本文源码解析使用的版本是 skywalking 7.0 , 不同版本实现上可能由一定差异，但是思想上大致相同
上篇文章介绍了skywalking-agent的整体架构以及插件的加载原理。
但是仅仅知道了他如何去加载插件，那至于在他使用agent去修改业务代码后如何去收集trace数据 那么请继续往下看
在看源码之前，我们先来了解一下 在skywalking中trace数据 是以什么样的数据结构去保存的，这里为了更清晰展示，这里选择从前端查看trace数据的结构
本文涉及到的源码取自版本 : apache-skywalking-apm-7.0.0 ,不同版本实现差异可能会有一些区别,但是大体框架上没有变化的 , 一些地方为了方便理解,我拆分了 lamda 表达式,或者把一些写在一起的代码给做了拆分,但是整体逻辑是不变的
skywalking 是一个 分布式追踪系统 , 他可以帮助我们看到一个请求经过了多少个微服务,中途调用了多少数据库,redis,mq 等中间件, 要实现这样的功能,其实很简单只要在设计系统的时候, 每经过一次请求,每调用一次中间件,都把对应的日志给存起来, 然后提供一个 ui 服务,也同样能实现对应的功能. 但是如果这样做的话, 对代码就有很强的侵入性 , 每一个业务系统都需要修改,在业务代码里去加上对应的日志,对于喜欢偷懒的程序员来说,这是非常不舒服的.
做开发的人都知道自动化测试，自动化测试不需要人为去触发一个个行为，系统自动运行测试用例。价值不言而喻，但是如果自动化测试用例的缺失部分导致系统没完整测试回归可能会给系统带来风险。这里就是流量回放的价值：通过记录线上流量，在开发或者测试环境回放，来发现系统是否能够正常运行，降低代码变动整体系统带来的风险。
通过AOP请求和响应的拦截，并且进行请求和响应的记录，在开发环境通过解析结果进行回放。
面向切面编程，spring的AOP就是一种实现。当然还可以很多其他实现，例如基于jvm的AOP，可以通过在通过装饰jvm中的class实现；例如其他语言也有对应的实现
如果你问自己是否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()方法来获取序列中的下一个值。使用反应式流时采用的则是推的方式，即常见的发布者-订阅者模式。当发布者有新的数据产生时，这些数据会被推送到订阅者来进行处理。在反应式流上可以添加各种不同的操作来对数据进行处理，形成数据处理链。这个以声明式的方式添加的处理链只在订阅者进行订阅操作时才会真正执行。