CAS:Compare and Swap, 翻译成比较并交换。
java.util.concurrent包中借助CAS实现了区别于synchronouse同步锁的一种乐观锁。
CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。
一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。
现代的CPU提供了特殊的指令，可以自动更新共享数据，而且能够检测到其他线程的干扰，而 compareAndSet() 就用这些代替了锁定。
拿出AtomicInteger来研究在没有锁的情况下是如何做到数据正确性的。
private volatile int value;
在没有锁的机制下可能需要借助volatile原语，保证线程间的数据是可见的（共享的）。
这样才获取变量的值的时候才能直接读取。
jdk8对ConcurrentHashMap做了很大的调整，首先因为HashMap在jdk8已经做了数据结构上的优化，增加了红黑树。所以，jdk7针对ConcurrentHashMap的改进，主要是增加了分段锁Segment对HashEntity的控制，完美的解决了HashMap的安全问题，在JMM中有个名称叫安全发布，已经不适用了。
那么，在jdk8如果保持性能的情况下对其进行修改了？它到底做了那些事情呢？
我们将数组称之为表，将数组中每个链表或红黑树称之为桶，将数组中的每个结点称之为槽，也就是说“槽”存储了链表的头结点或者红黑树的根结点。源代码中用内部类Node表示链表中的每个结点。
导读：目前为止 IT 产业经历了六次浪潮，分别为：大型机时代，小型机时代，个人电脑时代，桌面互联网时代，移动互联网时代和 AIOT 时代。在这些时代背后可以发现是人机交互方式的变化：从鼠键交互，到触控交互，再到语音智能交互，可以看到人机交互的方式在向更自然更直接化的方式演进。今天会和大家分享基于知识图谱的问答在美团智能交互场景中的应用和演进。
今天的介绍会围绕下面三点展开：
1. 智能交互的划分
智能交互的划分基本上是根据人类需求拆分：
Skaffold is a command line tool that facilitates continuous development for Kubernetes applications. You can iterate on your application source code locally then deploy to local or remote Kubernetes clusters. Skaffold handles the workflow for building, pushing and deploying your application. It also provides building blocks and describe customizations for a CI/CD pipeline.
git clone and skaffold runskaffold run end-to-end or just part of skaffold stages from build to deployment in your CI/CD systemTo keep Skaffold up to date, update checks are made to Google servers to see if a new version of Skaffold is available.
You can turn this update check off by following these instructions.
Your use of this software is subject to the Google Privacy Policy
For the latest stable release download and place it in your PATH:
https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
Run these commands to download and place the binary in your /usr/local/bin folder:
curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/binFor the latest bleeding edge build, download and place it in your PATH:
https://storage.googleapis.com/skaffold/builds/latest/skaffold-linux-amd64
Run these commands to download and place the binary in your /usr/local/bin folder:
curl -Lo skaffold https://storage.googleapis.com/skaffold/builds/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin
Skaffold simplifies your development workflow by organizing common development stages into one simple command. Every time you run skaffold dev, the system
What’s more, the pluggable architecture is central to Skaffold’s design, allowing you to use the tool you prefer in each stage. Also, Skaffold’s profiles feature grants you the freedom to switch tools as you see fit depending on the context.
For example, if you are coding on a local machine, you can configure Skaffold to build artifacts with local Docker daemon and deploy them to minikube using kubectl, the Kubernetes command-line interface and when you finalize your design, you can switch to the production profile and start building with Google Cloud Build and deploy with Helm.
Skaffold supports the following tools:
kubectl)
Besides the above steps, skaffold also automatically manages the following utilities for you:
kubectl port-forwardDocumentation for latest release: https://skaffold.dev
Documentation for latest build: https://skaffold-latest.firebaseapp.com
随着移动互联网的发展，用户使用习惯日趋碎片化，如何让用户在有限的访问时间里找到想要的产品，成为了搜索/推荐系统演进的重要职责。作为外卖领域的独角兽, 饿了么拥有百万级的日活跃用户，如何利用数据挖掘/机器学习的方法挖掘潜在用户、增加用户粘性，已成为迫切需要解决的问题。
个性化推荐系统通过研究用户的兴趣偏好，进行个性化计算，发现用户的兴趣点，从而引导用户发现自己的信息需求。一个好的推荐系统不仅能为用户提供个性化的服务，还能和用户之间建立密切关系，让用户对推荐产生依赖。
本次分享介绍饿 了么如何从0到1构建一个可快速迭代的推荐系统，从产品形态出发，包括推荐模型与特征工程、日志处理与效果评估，以及更深层次的场景选择和意图识别。
在携程个性化推荐与人工智能meetup上，已经就以上几部分做了整体上的说明，本文将就其中模型排序与特征计算的线上实现做具体说明，同时补充有关业务规则相关的洗牌逻辑说明，力图从细节上还原和展示饿了么美食推荐系统。
对于任何一个外部请求, 系统都会构建一个QueryInfo(查询请求), 同时从各种数据源提取UserInfo(用户信息)、ShopInfo(商户信息)、FoodInfo(食物信息)以及ABTest配置信息等, 然后调用Ranker排序。以下是排序的基本流程(如下图所示)：
物理上，Hbase 是由三种类型的 server 组成的的主从式（master-slave）架构：
当然底层的存储都是基于 Hadoop HDFS 的：
这是一篇全面介绍 WebKit 和 Gecko 内部操作的入门文章，是以色列开发人员塔利·加希尔大量研究的成果。在过去的几年中，她查阅了所有公开发布的关于浏览器内部机制的数据，并花了很多时间来研读网络浏览器的源代码。她写道：
“在 IE 占据 90% 市场份额的年代，我们除了把浏览器当成一个“黑箱”，什么也做不了。但是现在，开放源代码的浏览器拥有了过半的市场份额，因此，是时候来揭开神秘的面纱，一探网络浏览器的内幕了。呃，里面只有数以百万行计的 C++ 代码…”
塔利在她的网站上公布了自己的研究成果，但是我们觉得它值得让更多的人来了解，所以我们在此重新整理并公布。
RPC（Remote Procedure Call）—远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。现在业界有很多开源的优秀 RPC 框架，例如 Spring Cloud、Dubbo、Thrift 等。
RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出。这里我们追溯下当初开发 RPC 的原动机是什么？在 Nelson 的论文 “Implementing Remote Procedure Calls” 中他提到了几点：
Dubbo 服务调用过程比较复杂，包含众多步骤，比如发送请求、编解码、服务降级、过滤器链处理、序列化、线程派发以及响应请求等步骤。限于篇幅原因，本篇文章无法对所有的步骤一一进行分析。本篇文章将会重点分析请求的发送与接收、编解码、线程派发以及响应的发送与接收等过程，至于服务降级、过滤器链和序列化大家自行进行分析，也可以将其当成一个黑盒，暂时忽略也没关系。
在进行源码分析之前，我们先来通过一张图了解 Dubbo 服务调用过程。
首先服务消费者通过代理对象 Proxy 发起远程调用，接着通过网络客户端 Client 将编码后的请求发送给服务提供方的网络层上，也就是 Server。Server 在收到请求后，首先要做的事情是对数据包进行解码。然后将解码后的请求发送至分发器 Dispatcher，再由分发器将请求派发到指定的线程池上，最后由线程池调用具体的服务。
LoadBalance 中文意思为负载均衡，它的职责是将网络请求，或者其他形式的负载“均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况。通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。在为高负载服务器分流的同时，还可以避免资源浪费，一举两得。
负载均衡可分为软件负载均衡和硬件负载均衡。在我们日常开发中，一般很难接触到硬件负载均衡。但软件负载均衡还是可以接触到的，比如 Nginx。在 Dubbo 中，也有负载均衡的概念和相应的实现。Dubbo 需要对服务消费者的调用请求进行分配，避免少数服务提供者负载过大。服务提供者负载过大，会导致部分请求超时。因此将负载均衡到每个服务提供者上，是非常必要的。
Dubbo 提供了4种负载均衡实现，分别是基于权重随机算法的 RandomLoadBalance、基于最少活跃调用数算法的 LeastActiveLoadBalance、基于 hash 一致性的 ConsistentHashLoadBalance，以及基于加权轮询算法的 RoundRobinLoadBalance。这几个负载均衡算法代码不是很长，但是想看懂也不是很容易，需要大家对这几个算法的原理有一定了解才行。如果不是很了解，也没不用太担心。我们会在分析每个算法的源码之前，对算法原理进行简单的讲解，帮助大家建立初步的印象。
研发人员在遇到线上报警或需要优化系统性能时，常常需要分析程序运行行为和性能瓶颈。Profiling技术是一种在应用运行时收集程序相关信息的动态分析手段，常用的JVM Profiler可以从多个方面对程序进行动态分析，如CPU、Memory、Thread、Classes、GC等，其中CPU Profiling的应用最为广泛。CPU Profiling经常被用于分析代码的执行热点，如“哪个方法占用CPU的执行时间最长”、“每个方法占用CPU的比例是多少”等等，通过CPU Profiling得到上述相关信息后，研发人员就可以轻松针对热点瓶颈进行分析和性能优化，进而突破性能瓶颈，大幅提升系统的吞吐量。
本文介绍了JVM平台上CPU Profiler的实现原理，希望能帮助读者在使用类似工具的同时也能清楚其内部的技术实现。
社区实现的JVM Profiler很多，比如已经商用且功能强大的JProfiler，也有免费开源的产品，如JVM-Profiler，功能各有所长。我们日常使用的Intellij IDEA最新版内部也集成了一个简单好用的Profiler，详细的介绍参见官方Blog。
Raft作为一种比较好理解的分布式一致性算法（相对于paxos来说，其实要理解还是有点难度的！），是通过选举机制，日志复制来保证发布式系统数据的一致性。
相对于Paxos算法，Raft引入主节点，通过竞选。其中节点类型：
Leader 会周期性的发送心跳包给 Follower。每个 Follower 都设置了一个随机的竞选超时时间，一般为 150ms~300ms，如果在这个时间内没有收到 Leader 的心跳包，就会变成 Candidate，进入竞选阶段。
流程：
① 下图表示一个分布式系统的最初阶段，此时只有 Follower，没有 Leader。Follower A 等待一个随机的竞选超时时间之后，没收到 Leader 发来的心跳包，因此进入竞选阶段。
为了避免单点故障，现在的应用通常至少会部署在两台服务器上。对于一些负载比较高的服务，会部署更多的服务器。这样，在同一环境下的服务提供者数量会大于1。对于服务消费者来说，同一环境下出现了多个服务提供者。这时会出现一个问题，服务消费者需要决定选择哪个服务提供者进行调用。另外服务调用失败时的处理措施也是需要考虑的，是重试呢，还是抛出异常，亦或是只打印异常等。
为了处理这些问题，Dubbo 定义了集群接口 Cluster 以及 Cluster Invoker。集群 Cluster 用途是将多个服务提供者合并为一个 Cluster Invoker，并将这个 Invoker 暴露给服务消费者。这样一来，服务消费者只需通过这个 Invoker 进行远程调用即可，至于具体调用哪个服务提供者，以及调用失败后如何处理等问题，现在都交给集群模块去处理。集群模块是服务提供者和服务消费者的中间层，为服务消费者屏蔽了服务提供者的情况，这样服务消费者就可以专心处理远程调用相关事宜。比如发请求，接受服务提供者返回的数据等。这就是集群的作用。
Dubbo 提供了多种集群实现，包含但不限于 Failover Cluster、Failfast Cluster 和 Failsafe Cluster 等。每种集群实现类的用途不同，接下来会一一进行分析。
Dubbo整体框架可以参考下图
图例说明：
SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。
在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。
需要特别说明的是，本篇文章以及本系列其他文章所分析的源码版本均为 dubbo-2.6.4。因此大家在阅读文章的过程中，需注意将代码版本切换到 dubbo-2.6.4 tag 上。
断点调试是我们最常使用的调试手段，它可以获取到方法执行过程中的变量信息，并可以观察到方法的执行路径。但断点调试会在断点位置停顿，使得整个应用停止响应。在线上停顿应用是致命的，动态调试技术给了我们创造新的调试模式的想象空间。
本文将研究Java语言中的动态调试技术，首先概括Java动态调试所涉及的技术基础，接着介绍我们在Java动态调试领域的思考及实践，通过结合实际业务场景，设计并实现了一种具备动态性的断点调试工具Java-debug-tool，显著提高了故障排查效率。
Kubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统，它大幅降低了容器化应用部署的门槛，但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。
Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力，完成集群的创建、升级和工作节点的管理。在大规模场景下，集群变更的可控性直接关系到集群的稳定性，因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景，并能够从这些异常场景中自恢复。
功能
设计要点
随着移动互联网的发展和智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作，集群按照分布式理论构建出庞大复杂的应用服务，在分布式的基础上正进行一场云原生的技术革命，彻底打破传统的开发方式，解放了新一代的生产力。
API 网关提供完整的 API 托管服务，辅助用户将能力、服务、数据以 API 的形式开放给合作伙伴，也可以发布到 API 市场供更多的开发者采购使用。
API托管服务: 为企业与开发者提供低成本、高可用、安全、便捷、易于管理的 API 开发能力。
在 API 的市场里，日均调用次数已经超过1.2亿次，基于此背景，阿里云全新探索了云市场能力中心，建立 API 生态，为企业客户和伙伴提供 API 购买和 API 变现一站式解决方案。API 网关将能力的复用率最大化，让企业之间能够互相借力，企业发展能够专注自身业务，实现共赢。
了解Spring中AOP的人都知道，其AOP实现原理是基于Java动态代理和CGLIB代理两种方式实现的，其实Java语言中除了上述两种外，还有其它三种实现技术，也是它们支撑着Arthas和CAT的底层核心原理：
Serverless（无服务器架构）是指服务端逻辑由开发者实现，运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。
Serverless 是云原生技术发展的高级阶段，可以使开发者更聚焦在业务逻辑，而减少对基础设施的关注。
下图来自谷歌云平台官网，是对云计算的一个很好的分层概括，其中 serverless 就是构建在虚拟机和容器之上的一层，与应用本身的关系更加密切。
当应用上线以后，运维面临的一大挑战是如何能够在不影响已上线业务的情况下进行升级。做过产品的同学都清楚，不管在发布前做过多么完备的自动化和人工测试，在发布后都会出现或多或少的故障。根据墨菲定律，可能会出错的版本发布一定会出错。
“ANYTHING THAN CAN GO WRONG WILL GO WRONG”
—— MURPHY’S LAW
因此我们不能寄希望于在线下测试时发现所有潜在故障。在无法百分百避免版本升级故障的情况下，需要通过一种方式进行可控的版本发布，把故障影响控制在可以接受的范围内，并可以快速回退。
可以通过灰度发布（又名金丝雀发布）来实现业务从老版本到新版本的平滑过渡，并避免升级过程中出现的问题对用户造成的影响。
本文主要包括推荐系统的相关概念、推荐系统的架构和流程、常见的推荐算法、挖掘、召回、排序、评估和总结这几部分。
概念部分会简述推荐系统相关的理论知识，架构和流程主要是介绍推荐系统的通用架构和常规的推荐流程。
算法部分主要是一些常见的推荐算法介绍，挖掘》召回》排序主要是基于推荐流程的详细展开。
评估部分指的是如何评估一个推荐系统的好坏，总结部分主要是整体内容的回顾，以及一个真实推荐系统的案例。
先来看下Wiki的定义：
一种信息过滤系统，用来预测用户对物品的行为和偏好。
按照字面意思理解下来，就是帮助过滤信息，预测用户对物品的行为和偏好。
在今日头条曹欢欢博士的一次分享中提到了这样一个定义：
资讯推荐系统本质上要解决用户，资讯和环境的匹配，y=F(Xi,Xu,Xc)
感觉把这个定义延伸到其他推荐系统上也是成立的，那就是推荐系统本质上要解决用户，物品和环境的匹配问题，帮助建立用户和物品之间的连接。
回到定义本身，理论上说能实现这个功能的系统都可以称之为推荐系统。