分布式算法

多级缓存的分层架构 前言 在互联网高速发展的今天，缓存技术被广泛地应用。无论业内还是业外，只要是提到性能问题，大家都会脱口而出“用缓存解决”。 这种说法带有片面性，甚至是一知半解，但是作为专业人士的我们，需要对缓存有更深、更广的了解。 缓存技术存在于应用场景的方方面面。从浏览器请求，到反向代理服务器，从进程内缓存到分布式缓存。其中缓存策略，算法也是层出不穷，今天就带大家走进缓存。 正文 缓存对于每个开发者来说是相当熟悉了，为了提高程序的性能我们会去加缓存，但是在什么地方加缓存，如何加缓存呢？ 假设一个网站，需要提高性能，缓存可以放在浏览器，可以放在反向代理服务器，还可以放在应用程序进程内，同时可以放在分布式缓存系统中。 从用户请求数据到数据返回，数据经过了浏览器，CDN，代理服务器，应用服务器，以及数据库各个环节。每个环节都可以运用缓存技术。 从浏览器/客户端开始请求数据，通过 HTTP 配合 CDN 获取数据的变更情况，到达代理服务器（Nginx）可以通过反向代理获取静态资源。 再往下来到应用服务器可以通过进程内（堆内）缓存，分布式缓存等递进的方式获取数据。如果以上所有缓存都没有命中数据，才会回源到数据库。 缓存的请求顺序是：用户请求 → HTTP 缓存 → CDN 缓存 → 代理服务器缓存 → 进程内缓存 → 分布式缓存 → 数据库。 看来在技术的架构每个环节都可以加入缓存

分布式ID生成算法的有很多种，Twitter的SnowFlake就是其中经典的一种。 Snowflake工作原理 对于分布式的ID生成，以Twitter Snowflake为代表的Flake 系列算法，属于划分命名空间并行生成的一种算法，生成的数据为64bit的long型数据，在数据库中应该用大于等于64bit的数字类型的字段来保存该值，比如在MySQL中应该使用BIGINT。 SnowFlake算法生成ID的结构如下图： 1 符号位 等于 0 41 时间戳 从 2016 / 11 / 01 零点开始的毫秒数，支持 2 ^ 41 / 365 / 24 / 60 / 60 / 1000 = 69 .7年 10 工作进程编号 支持 1024 个进程 12 序列号 每毫秒从 0 开始自增，支持 4096 个编号 Sharding-jdbc实现的雪花算法核心源码解读： 源码地址：https://github.com/apache/incubator-shardingsphere/blob/dev/sharding-core/sharding-core-common/src/main/java/org/apache/shardingsphere/core/strategy/keygen/SnowflakeShardingKeyGenerator.java} /* * Licensed to

一：基本构成：HDFS（Hadoop分布式文件系统）；Mapreduce（分布式计算框架）；HBASE（分布式列存数据库）； Zookeeper（分布式协作服务）； HIVE（数据仓库）；Pig(ad-hoc脚本）等。 二：详细了解一下其特性： Hadoop是一个由Apache基金会所开发的分布式系统基础架构。 用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 具有可靠、高效、可伸缩的特点。 Hadoop的核心是YARN,HDFS和Mapreduce 下图是hadoop生态系统，集成spark生态圈。在未来一段时间内，hadoop将于spark共存，hadoop与spark 都能部署在yarn、mesos的资源管理系统之上 组件简介： 1.HDFS（Hadoop分布式文件系统） 源自于Google的GFS论文，发表于2003年10月，HDFS是GFS克隆版。 HDFS是Hadoop体系中数据存储管理的基础。它是一个高度容错的系统，能检测和应对硬件故障，用于在低成本的通用硬件上运行。 HDFS简化了文件的一致性模型，通过流式数据访问，提供高吞吐量应用程序数据访问功能，适合带有大型数据集的应用程序。 它提供了一次写入多次读取的机制，数据以块的形式，同时分布在集群不同物理机器上。 2.Mapreduce （分布式计算框架）

原地址：http://bigdata.idcquan.com/dsjjs/159544.shtml 大数据 技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算、可视化等各种技术范畴和不同的技术层面。首先给出一个通用化的大数据处理框架，主要分为下面几个方面：数据采集与预处理、数据存储、数据清洗、数据查询分析和数据可视化。 一、数据采集与预处理 对于各种来源的数据，包括移动互联网数据、社交网络的数据等，这些结构化和非结构化的海量数据是零散的，也就是所谓的数据孤岛，此时的这些数据并没有什么意义，数据采集就是将这些数据写入数据仓库中，把零散的数据整合在一起，对这些数据综合起来进行分析。数据采集包括文件日志的采集、数据库日志的采集、关系型数据库的接入和应用程序的接入等。在数据量比较小的时候，可以写个定时的脚本将日志写入存储系统，但随着数据量的增长，这些方法无法提供数据安全保障，并且运维困难，需要更强壮的解决方案。 Flume NG作为实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据，同时，对数据进行简单处理，并写到各种数据接收方(比如文本，HDFS，Hbase等)。Flume NG采用的是三层架构：Agent层，Collector层和Store层，每一层均可水平拓展。其中Agent包含Source

在分布式算法领域，有个非常重要的算法叫Paxos, 它的重要性有多高呢，Google的Chubby [1]中提到 all working protocols for asynchronous consensus we have so far encountered have Paxos at their core. 关于Paxos算法的详述在维基百科中有更多介绍，中文版介绍的是choose value的规则[2]，英文版介绍的是Paxos 3 phase commit的流程[3]，中文版不是从英文版翻译而是独立写的，所以非常具有互补性。Paxos算法是由Leslie Lamport提出的，他在Paxos Made Simple[4]中写道 The Paxos algorithm, when presented in plain English, is very simple. 当你研究了很长一段时间Paxos算法还是有点迷糊的时候，看到上面这句话可能会有点沮丧。但是公认的它的算法还是比较繁琐的，尤其是要用程序员严谨的思维将所有细节理清的时候，你的脑袋里更是会充满了问号。Leslie Lamport也是用了长达9年的时间来完善这个算法的理论。 实际上对于一般的开发人员，我们并不需要了解Paxos所有细节及如何实现，只需要知道Paxos是一个分布式选举算法就够了

一、问题： 数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。 二、解决方案： 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 （这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop+HBase+Hive等分布式存储分析平台） 三、主流解Cache和数据库对比： 上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。 从以上各数据可知，对于我们产品最可行的技术方案有两种： 1.Memcached 内存Key-Value Cache 2.Redis 内存数据库 四、下面重点分析Memcached和Redis两种方案： 4.1 Memcached介绍 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook

一、问题： 数据库表数据量极大（千万条），要求让服务器更加快速地响应用户的需求。 二、解决方案： 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 （这里仅从数据缓存方面考虑，当然，后期可以采用Hadoop+HBase+Hive等分布式存储分析平台） 三、主流解Cache和数据库对比： 上述技术基本上代表了当今在数据存储方面所有的实现方案，其中主要涉及到了普通关系型数据库（MySQL/PostgreSQL），NoSQL数据库(MongoDB)，内存数据库（Redis），内存Cache（Memcached），我们现在需要的是对大数据表仍保持高效的查询速度，普通关系型数据库是无法满足的。而MongoDB其实只是一种非关系型数据库，其优势在于可以存储海量数据，具备强大的查询功能，因此不宜用于缓存数据的场景。 从以上各数据可知，对于我们产品最可行的技术方案有两种： 1.Memcached 内存Key-Value Cache 2.Redis 内存数据库 四、下面重点分析Memcached和Redis两种方案： 4.1 Memcached介绍 Memcached 是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提供动态、数据库驱动网站的速度，现在已被LiveJournal、hatena、Facebook

前言 题目有点大，所以不可能说得非常具体，笔者也不能驾驭全部。 前面介绍过 网站发展过程中架构的演化过程 ,本文主要针对网站架构各个方面的建设进行简单介绍。 架构模式 先来说说模式： 每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地用该方案而不必做重复工作 。 先来说说常见的网站架构模式。这里没有涉及具体实现过程，只是简单介绍其思想和原理，方便日后有用到再深入了解。 分层 分层是企业应用系统中最常见的一种架构模式，将系统在 横向维度 上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后 通过上层对下层的依赖和调用 组成一个完整的系统。 分层 功能 应用层 负责具体业务和视图展示，如网站首页以及搜索输入和结果展示 服务层 为应用层提供服务支持，如用户管理服务，购物车服务 数据层 提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等 分层架构 还可以细分下去 ，比如说应用层可以细分为视图层和业务逻辑层。服务层可以细分为数据接口层和逻辑处理层。 分层结构对网站支持高并发向分布式发展至关重要，所以 在网站规模很小的时候就应该采用分层的架构，这样将来网站做大时才能有更好地应对 。 所以说我们在设计一个新项目的架构时，就需要考虑到分层。不能等到日后项目做大了，再重构就耗时耗力了。 分割 上面的分层是将软件在横向方面进行切分，而分割是在

　　一个大型稳健成熟的分布式系统的背后，往往会设计众多的支撑组件，将这些支撑系统成为分布式系统的基础设施。进行系统架构设计所依赖的基础设施，还包括分布式协作及配置管理组件、分布式缓存组件、持久化存储组件、分布式消息系统、搜索引擎、以及CDN系统、负载均衡系统、运维自动化系统等，还有实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等。此处主要讲讲缓存系统组件。 缓存组件层 缓存系统带来的好处： 加速读写。缓存通常是全内存的，比如Redis、Memcache。对内存的直接读写会比传统的存储层如MySQL，性能好很多。由于单台机器的内存资源和承载能力有限，并且如果大量使用本地缓存，也会使相同的数据被不同的节点存储多份，对内存资源造成较大的浪费，因此才催生出了分布式缓存。 降低后端的负载。在高并发环境下，大量的读、写请求涌向数据库，磁盘的处理速度与内存显然不在一个量级，从减轻数据库的压力和提供系统响应速度两个角度来考虑，一般都会在数据库之前加一层缓存。 缓存系统带来的成本： 数据不一致性：在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署(为了保证可用性，一定是部署多份的)，对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成(读出脏数据) 代码维护成本：加入缓存后

ZooKeeper是一种 分布式协调服务 ，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。 ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。 例如，Apache HBase使用ZooKeeper跟踪分布式数据的状态。 分布式的相関概念 分布式应用：分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。 集群：分布式应用正在运行的一组系统称为集群 节点：在集群中运行的每台机器被称为节点 分布式应以由两部分组成，分别是客户端和服务器。服务器应用程序实际上是分布式的，并具有通用接口，客户端访问任意一台服务器都可以获得相同的结果。 什么是ZooKeeper ZooKeeper是由集群（节点组）使用的 一种服务 ，用于在 自身之间协调 ，并通过稳健的 同步技术维护共享数据 。ZooKeeper本身是一个分布式应用程序，为写入分布式应用程序 提供服务 。 ZooKeeper的特点： 简单、同步、有序、序列化、可靠性、原子性