微笑的周末

dubbo是什么 dubbo是一个分布式框架，远程服务调用的分布式框架，其核心部分包含：集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。远程通讯： 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。 dubbo能做什么 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 1、默认使用的是什么通信框架，还有别的选择吗? 答：默认也推荐使用 netty 框架，还有 mina。 2、服务调用是阻塞的吗？ ...

本文由 简悦 SimpRead 转码， 原文地址 https://juejin.im/post/5bade237e51d450ea401fd71?utm_source=gold_browser_extension 《对象搜索算法与回收算法》介绍了垃圾回收的基础算法，相当于垃圾回收的方法论。接下来就详细看看垃圾回收的具体实现。 上文提到过现代的商用虚拟机的都是采用分代收集的，不同的区域用不同的收集器。常用的 7 种收集器，其适用的范围如图所示 Serial、ParNew、Parallel Scavenge 用于新生代；CMS、Serial Old、Paralled Old 用于老年代。 并且他们相互之间以相对固定的组合使用（具体组合关系如上图）。G1 是一个独立的收集器不依赖其他 6 种收集器。ZGC 是目前 JDK 11 的实验收集器。 下面来看看各个收集器的特性 Serial 收集器Serial，是单线程执行垃圾回收的。当需要执行垃圾回收时，程序会暂停一切手上的工作，然后单线程执 ...

本文由 简悦 SimpRead 转码， 原文地址 http://www.6aiq.com/article/1523271021117 让代码分布式运行是所有分布式计算框架需要解决的最基本的问题。Spark 是大数据领域中相当火热的计算框架，在大数据分析领域有一统江湖的趋势，网上对于 Spark 源码分析的文章有很多，但是介绍 Spark 如何处理代码分布式执行问题的资料少之又少，这也是我撰写文本的目的。 Spark 运行在 JVM 之上，任务的执行依赖序列化及类加载机制，因此本文会重点围绕这两个主题介绍 Spark 对代码分布式执行的处理。本文假设读者对 Spark、Java、Scala 有一定的了解，代码示例基于 Scala，Spark 源码基于 2.1.0 版本。阅读本文你可以了解到： Java 对象序列化机制 类加载器的作用 Spark 对 closure 序列化的处理 Spark Application 的 class 是如何加载的 Spark REPL（spa ...

本文由 简悦 SimpRead 转码， 原文地址 https://www.cnblogs.com/wxgblogs/p/6639272.html 　　WEB 资源或 API 方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性是系统的接口对外一种承诺 (而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的。幂等性是分布式系统设计中的一个重要概念，对超时处理、系统恢复等具有重要意义。声明为幂等的接口会认为外部调用失败是常态, 并且失败之后必然会有重试。例如，在因网络中断等原因导致请求方未能收到请求返回值的情况下，如果该资源具备幂等性，请求方只需要重新请求即可，而无需担心重复调用会产生错误。实际上，我们常用的 HTTP 协议的方法是具有幂等性语义要求的，比如：get 方法用于获取资源，不应有副作用，因此是幂等的；post 方法用于创建资源，每次请求都会产生新的资源，因此不具备幂等性；put 方法用于更新资源，是幂等的；delete 方法用于删除资源，也 ...

本文由 简悦 SimpRead 转码， 原文地址 http://www.3xmq.com/article/1515685180389 作者 | 卫向军来自 | cnblogs 架构以及我理解中架构的本质 在开始谈我对架构本质的理解之前，先谈谈对今天技术沙龙主题的个人见解，千万级规模的网站感觉数量级是非常大的，对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级？现在很流行的优步 (Uber)，从媒体公布的信息看，它每天接单量平均在百万左右， 假如每天有 10 个小时的服务时间，平均 QPS 只有 30 左右。对于一个后台服务器，单机的平均 QPS 可以到达 800-1000，单独看写的业务量很简单 。为什么我们又不能说轻视它？第一，我们看它的数据存储，每天一百万的话，一年数据量的规模是多少？其次，刚才说的订单量，每一个订单要推送给附近的司机、司机要并发抢单，后面业务场景的访问量往往是前者的上百倍，轻松就超过上亿级别了。 今天 ...

本文由 简悦 SimpRead 转码， 原文地址 https://juejin.im/post/5b16148a518825136137c8db ————— 第二天 ————— ———————————— 分布式锁的实现有哪些？ 1.Memcached 分布式锁 利用 Memcached 的 add 命令。此命令是原子性操作，只有在 key 不存在的情况下，才能 add 成功，也就意味着线程得到了锁。 2.Redis 分布式锁 和 Memcached 的方式类似，利用 Redis 的 setnx 命令。此命令同样是原子性操作，只有在 key 不存在的情况下，才能 set 成功。（setnx 命令并不完善，后续会介绍替代方案） 3.Zookeeper 分布式锁 利用 Zookeeper 的顺序临时节点，来实现分布式锁和等待队列。Zookeeper 设计的初衷，就是为了实现分布式锁服务的。 4.Chubby Google 公司实现的粗粒度分布式锁服务， ...

RabbitMQ之Docker构建 因为分布式项目中使用了rabbitmq的组件，故此写文关于采用官方的镜像完成基于docker的rabbitmq的搭建。 准备基础环境 首先在系统中安装docker的相关软件，本文基于系统ubuntu 18.04版本构建，docker version 17.12 安装docker，网上很多文章不载赘述 获取镜像docker pull rabbitmq:management 启动实例docker run -d --hostname dean-rabbit -p 5671:5671 -p 5672:5672 -p 4369:4369 -p 25672:25672 -p 15671:15671 -p 15672:15672 --name dean-rabbit rabbitmq:management 15672端口为web ui界面默认端口，可以通过访问地址http://localhost:15671 默认用户名和密码：guest/guest

本文由 简悦 SimpRead 转码， 原文地址 https://juejin.im/post/5a215783f265da431d3c7bba ​ ———————————— 众所周知，HashMap 是一个用于存储 Key-Value 键值对的集合，每一个键值对也叫做 Entry。这些个键值对（Entry）分散存储在一个数组当中，这个数组就是 HashMap 的主干。 HashMap 数组每一个元素的初始值都是 Null。 对于 HashMap，我们最常使用的是两个方法：Get 和 Put。 1.Put 方法的原理 调用 Put 方法的时候发生了什么呢？ 比如调用 hashMap.put(“apple”, 0) ，插入一个 Key 为 “apple” 的元素。这时候我们需要利用一个哈希函数来确定 Entry 的插入位置（index）： index = Hash（“apple”） 假定最后计算出的 index 是 2，那么结果如下： 但是，因为 HashMap ...

本文由 简悦 SimpRead 转码， 原文地址 https://juejin.im/post/5a224e1551882535c56cb940 ​上一期我们介绍了 HashMap 的基本原理，没看过的小伙伴们可以点击下面的链接： 漫画：什么是 HashMap？ 这一期我们来讲解高并发环境下，HashMap 可能出现的致命问题。 HashMap 的容量是有限的。当经过多次元素插入，使得 HashMap 达到一定饱和度时，Key 映射位置发生冲突的几率会逐渐提高。 这时候，HashMap 需要扩展它的长度，也就是进行 Resize。 影响发生 Resize 的因素有两个： 1.Capacity HashMap 的当前长度。上一期曾经说过，HashMap 的长度是 2 的幂。 2.LoadFactor HashMap 负载因子，默认值为 0.75f。 衡量 HashMap 是否进行 Resize 的条件如下： HashMap.Size >= Capacity * L* ...

本文由 简悦 SimpRead 转码， 原文地址 https://juejin.im/post/5af80310f265da0b8636585e 发出一个固定金额的红包，由若干个人来抢，需要满足哪些规则？ 1. 所有人抢到金额之和等于红包金额，不能超过，也不能少于。 2. 每个人至少抢到一分钱。 3. 要保证所有人抢到金额的几率相等。 小灰的思路是什么样呢？ 每次抢到的金额 = 随机区间 (0, 剩余金额) 为什么这么说呢？让我们看一个栗子： 假设有 10 个人，红包总额 100 元。 第一个人的随机范围是（0，100 元)，平均可以抢到 50 元。 假设第一个人随机到 50 元，那么剩余金额是 100-50 = 50 元。 第二个人的随机范围是 （0， 50 元），平均可以抢到 25 元。 假设第二个人随机到 25 元，那么剩余金额是 50-25 = 25 元。 第三个人的随机范围是 （0， 25 元），平均可以抢到 12.5 元。 以此类推，每一次随机范围越来越小。 ...