分布式算法

1.memcached：单一键值对内存缓存的，做对象缓存无可替代的分布式缓存； 2.redis：是算法和数据结构的集合，快速的数据结构操作是他最大的特点，支持数据持久化； 3.mongodb 是 bson 结构、介于 rdb 和 nosql 之间的，更松散更灵活的，但是不支持事务，只用作非重要数据存储。 转载请标明出处: Nosql 数据库 MemCache、Redis、MongoDB 的区别 文章来源: https://blog.csdn.net/tlsxtk/article/details/92084613

最新后端架构师技术图谱 深呼吸，慢慢学 ，技术长路漫漫… 数据结构 二叉树 完全二叉树 平衡二叉树 二叉查找树（BST） 红黑树 B-，B+，B*树 LSM 树 队列 集合 链表、数组 字典、关联数组 树 BitSet 常用算法 KPM 算法 选择排序 冒泡排序 插入排序 快速排序 归并排序 希尔排序 堆排序 计数排序 桶排序 基数排序 二分查找 Java 中的排序工具 排序、查找算法 布隆过滤器 字符串比较 深度优先、广度优先 贪心算法 回溯算法 剪枝算法 动态规划 朴素贝叶斯 推荐算法 最小生成树算法 最短路径算法 并发 Java中的锁和同步类 公平锁 & 非公平锁 悲观锁 & 乐观锁 & CAS ABA 问题 CopyOnWrite容器 RingBuffer 可重入锁 & 不可重入锁 互斥锁 & 共享锁 死锁 事务 ACID 特性 事务的隔离级别 多线程 线程安全 一致性、事务 锁 操作系统 计算机原理 进程 线程 协程 Linux 设计模式 康威定律 设计模式的六大原则 23种常见设计模式 应用场景 单例模式 责任链模式 MVC IOC AOP UML 微服务思想 运维 & 统计 & 技术支持 OpenStack Docker KVM Xen OpenVZ TDD 理论 单元测试 压力测试 全链路压测 A/B Test Ansible puppet chef Jenkins

在我们的工作中，数据库某些表的字段会用到唯一的，趋势递增的订单编号，我们将介绍两种方法，一种是传统的采用随机数生成的方式，另外一种是采用当前比较流行的“分布式唯一ID生成算法-雪花算法”来实现。 一、时间戳随机数生成唯一ID 我们写一个for循环，用RandomUtil.generateOrderCode()生成1000个唯一ID，执行结果我们会发现出现重复的ID。 /** * 随机数生成util **/ public class RandomUtil { private static final SimpleDateFormat dateFormatOne=new SimpleDateFormat("yyyyMMddHHmmssSS"); private static final ThreadLocalRandom random=ThreadLocalRandom.current(); //生成订单编号-方式一 public static String generateOrderCode(){ //TODO:时间戳+N为随机数流水号 return dateFormatOne.format(DateTime.now().toDate()) + generateNumber(4); } //N为随机数流水号 public static String generateNumber

目录： 一、什么是分布式系统？ 二、为什么要走分布式系统架构？ 三、系统如何进行拆分？ 四、分布式之后带来的技术挑战？ 一、什么是分布式系统？ 在谈分布式系统架构前，我们先来看看，什么是分布式系统？ 假设原来我们有一个系统，代码量30多万行。现在拆分成20个小系统，每个小系统1万多行代码。 原本代码之间都是直接基于Spring框架走JVM内存调用，现在拆开来，将20个小系统部署在不同的机器上，然后基于分布式服务框架（比如dubbo）搞一个rpc调用，接口与接口之间通过网络通信来进行请求和响应。 所以分布式系统很重要的特点就是服务间要跨网络进行调用，我们来看下面的图： 此外，分布式系统可以大概可以分成两类。 1. 底层的分布式系统。 比如hadoop hdfs（分布式存储系统）、spark（分布式计算系统）、storm（分布式流式计算系统）、elasticsearch（分布式搜索系统）、kafka（分布式发布订阅消息系统）等。 2. 分布式业务系统 分布式业务系统，把原来用java开发的一个大块系统，给拆分成多个子系统，多个子系统之间互相调用，形成一个大系统的整体。 举个例子，假设原来你做了一个OA系统，里面包含了权限模块、员工模块、请假模块、财务模块，一个工程，里面包含了一堆模块，模块与模块之间会互相去调用，1台机器部署。 现在如果你把他这个系统给拆开，权限系统，员工系统，请假系统

1、大数据流程图 2、大数据各个环节主要技术 在这里还是要推荐下我自己建的 大数据学习交流群:9437**91324 ，群里都是学大数据开发的，如果你正在学习大数据 ，小编欢迎你加入,大家都是软件开发党，不定期分享干货（只有大数据软件开发相关的），包括我自己整理的一份最新的大数据进阶资料和高级开发教程，欢迎进阶中和进想深入大数据的小伙伴加入。 2.1、数据处理主要技术 Sqoop ：（发音：skup）作为一款开源的离线数据传输工具，主要用于Hadoop(Hive) 与传统数据库（MySql,PostgreSQL）间的数据传递。它可以将一个关系数据库中数据导入Hadoop的HDFS中， 也可以将HDFS中的数据导入关系型数据库中。 Flume： 实时数据采集的一个开源框架，它是Cloudera提供的一个高可用用的、高可靠、分布式的海量日志采集、聚合和传输的系统。目前已经是Apache的顶级子项目。使用Flume可以收集诸如日志、时间等数据 并将这些数据集中存储起来供下游使用（尤其是数据流框架，例如Storm）。和Flume类似的另一个框架是Scribe（FaceBook开源的日志收集系统，它为日志的分布式收集、统一处理提供一个可扩展的、高容错的简单方案） 　Kafka： 通常来说Flume采集数据的速度和下游处理的速度通常不同步，因此实时平台架构都会用一个消息中间件来缓冲

Golang分布式并发---群体性热点淘汰算法 在传统的算法中，要计算热点的时候，常规采用，收集所有的任务列表，然后进行排序，得出前n的热点数据。此种算法的不好地方有： 1、 需要收集所有的任务列表。任务数过多时，收集是个问题 2、 将任务列表进行排序。在此过程中，如果列表过多，则会排序时间过长。 另外如果需要进行同步的话，则在此算法中，会有个停顿。 那么我们构建一个场景，一个网吧有n个位置，每个人都可以去网吧，但规定，每次只能预约1小时，如果时间到了，则可以续费继续一个小时，如果不需要则放弃位置。 现在有m个人来网吧上网。 1、m < n时，则m个人都可以获取到上网位置 2、当m>n时，则有n个人可以获取到上网位置，剩余的人，则在等待 有两种调度算法 1、 每个人，都会定期检查自己的时间，是不是到了1个小时，如果是，则判定自己是否需要继续使用，则优先续约1小时，如果不需要则放弃位置。等待的人中，则随机获取到这个位置。 2、每个人，都会定期检查自己的时间，是不是到了1个小时，如果是，则放弃位置。如果还需要继续使用则到等待队列中，不需要使用，则直接退出。 此算法中，需要注意的地方有 1、 每个用户自己是自律的。自己评判自己是否需要继续使用，评判自己是否时间到期等 2、 评判能否继续使用的标准，这个很重要。比如当个人贡献度到一定程度，才能继续使用。 简单的用法就是将n个体的贡献进行排序

区块链系统是一个分布式系统，而分布式系统的首要问题是一致性的保障。 一致性 　　定义：一致性（consistency），早期也叫agreement，是指对于分布式系统中的多个服务节点，给定一系列操作，在约定协议的保障下，试图使得他们对处理结果达成“某种程度”的认同。 一致性并不代表结果正确与否，而是系统对外呈现的状态一致与否；例如，所有节点都达成失败状态也是一种一致。 　　将可能引发不一致的并行操作进行串行化 是现代分布式系统处理一致性问题的的基础思路。 　　事件的先后顺序十分重要，这也是解决分布式系统领域很多问题的核心秘诀：把多件事情进行排序，并且这个顺序还得是大家都认可的。 共识算法 　　共识（consensus）在很多时候会与一致性（consistency）术语放在一起讨论。严谨地讲，两者的含义并不完全相同。 　　 一致性 往往指分布式系统中多个副本对外呈现的数据的 状态 。 共识 则描述了分布式系统中多个节点之间，彼此对某个状态达成一致结果的 过程 。因此，一致性描述的是结果状态，共识则是一种手段。达成某种共识并不意味着就保障了一致性。 　　在实践中，要保障系统满足不同程度的一致性，核心过程往往需要通过共识算法来达成。共识算法解决的是对某个提案（proposal） 大家达成一致意见的过程 。 提案的含义在分布式系统中十分宽泛，比如多个事件发生的顺序、某个键对应的值

1.ZooKeeper是一个开放源码的分布式协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。 Zookeeper保证了如下分布式一致性特性： 顺序一致性 原子性 单一视图 可靠性 实时性（最终一致性） 客户端的读请求可以被集群中的任意一台机器处理， 如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper机器来处理 。对于写请求，这些请求会同时发给其他zookeeper机器并且达成一致后，请求才会返回成功。因此，随着zookeeper的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降。 有序性是zookeeper中非常重要的一个特性，所有的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid（Zookeeper Transaction Id）。而读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的zxid。 Zookeeper提供了文件系统和通知机制。Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是

https://www.cnblogs.com/xybaby/p/10124083.html 正文   raft是工程上使用较为广泛的强一致性、去中心化、高可用的分布式协议。在这里强调了是在工程上，因为在学术理论界，最耀眼的还是大名鼎鼎的Paxos。但Paxos是：少数真正理解的人觉得简单，尚未理解的人觉得很难，大多数人都是一知半解。本人也花了很多时间、看了很多材料也没有真正理解。直到看到raft的论文，两位研究者也提到，他们也花了很长的时间来理解Paxos，他们也觉得很难理解，于是研究出了raft算法。    raft是一个共识算法（consensus algorithm），所谓共识，就是多个节点对某个事情达成一致的看法，即使是在部分节点故障、网络延时、网络分割的情况下。这些年最为火热的加密货币（比特币、区块链）就需要共识算法，而在分布式系统中，共识算法更多用于提高系统的容错性，比如分布式存储中的复制集（replication），在 带着问题学习分布式系统之中心化复制集 一文中介绍了中心化复制集的相关知识。raft协议就是一种leader-based的共识算法，与之相应的是leaderless的共识算法。   本文基于论文 In Search of an Understandable Consensus Algorithm 对raft协议进行分析，当然，还是建议读者直接看论文。

Hadoop与Spark比较 https://www.cnblogs.com/charlesblc/p/6206198.html 感觉自己落下好多东西没有学习 先看这篇文章：http://www.huochai.mobi/p/d/3967708/?share_tid=86bc0ba46c64&fmid=0 直接比较Hadoop和Spark有难度，因为它们处理的许多任务都一样，但是在一些方面又并不相互重叠。 比如说，Spark没有文件管理功能，因而必须依赖Hadoop分布式文件系统(HDFS)或另外某种解决方案。 Hadoop框架的主要模块包括如下： Hadoop Common Hadoop分布式文件系统(HDFS) Hadoop YARN Hadoop MapReduce 虽然上述四个模块构成了Hadoop的核心，不过还有其他几个模块。这些模块包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它们进一步增强和扩展了Hadoop的功能。 Spark确实速度很快(最多比Hadoop MapReduce快100倍)。Spark还可以执行批量处理，然而它真正擅长的是处理流工作负载、交互式查询和机器学习。 相比MapReduce基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。Spark与Hadoop及其模块兼容