分布式

在谈论缓存击穿之前，我们先来回忆下从缓存中加载数据的逻辑，如下图所示 因此，如果黑客每次故意查询一个在缓存内必然不存在的数据，导致每次请求都要去存储层去查询，这样缓存就失去了意义。如果在大流量下数据库可能挂掉。这就是缓存击穿。 场景如下图所示: 我们正常人在登录首页的时候，都是根据userID来命中数据，然而黑客的目的是破坏你的系统，黑客可以随机生成一堆userID,然后将这些请求怼到你的服务器上，这些请求在缓存中不存在，就会穿过缓存，直接怼到数据库上,从而造成数据库连接异常。 0 解决方案 在这里我们给出三套解决方案，大家根据项目中的实际情况，选择使用. 讲下述三种方案前，我们先回忆下redis的setnx方法 SETNX key value 将 key 的值设为 value ，当且仅当 key 不存在。 若给定的 key 已经存在，则 SETNX 不做任何动作。 SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。 可用版本 ：>= 1.0.0 时间复杂度： O(1) 返回值： 设置成功，返回 1。设置失败，返回 0 。 效果如下 redis> EXISTS job # job 不存在 (integer) 0 redis> SETNX job "programmer" # job 设置成功 (integer) 1 redis> SETNX

集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来，一个集群就象是一个服务实体，但事实上集群由一组服务实体组成。与单一服务实体相比较，集群提供了以下两个关键特性 ： 先说区别： 一句话：分布式是 串联 工作的，集群是 并联 工作的。 1：分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起，实现同一业务。 分布式中的每一个节点，都可以做集群。 而集群并不一定就是分布式的。 举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。 而分布式，从窄意上理解，也跟集群差不多， 但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。 分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。 2：简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。 例如： 如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行该任务需10小时。 采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。

本人不才，分享一下系统架构方面的知识，个人经历：单体应用架构--->分布式架构--->微服务架构 基本概念 单体应用架构: 只有一个项目，且所有功能部署在一起 分布式架构: 一个应用拆分成不同的业务，部署在不同的服务器上；分散服务器压力； 微服务架构: 分布式架构的延伸，进一步解耦复杂业务，多个微服务可以进行组合，组合后可以构成一个相对复杂的业务系统，以满足业务需求；目的是分散业务能力； 核心要素 《大型网站技术架构》中提到5大要素 性能 可用性 伸缩性 扩展性 安全性 详情可参考《大型网站技术架构》这本书以及这篇文章 http://www.cnblogs.com/me115/p/3662421.html 理解误区 架构师就是吹牛？ “架构实际上解决的是人的问题，而概念是人认识这个世界的基础”-----引自资深架构师王概凯《架构漫谈》架构师是一个很宽泛的说法，目的是为了解决实际问题与业务瓶颈； 分布式与集群？ 一个是工作方式，一个是物理形态，分布式是指将不同的业务分布在不同的地方；而集群指的是将几台服务器集中在一起，实现同一业务；分布式中的每一个节点，都可以做集群，而集群并不一定就是分布式的； 个人小结 入行近两年，业务越写越顺，坑越踩越多，最近开接触架构相关知识，参加过几次线下活动； 职业升级路线：初级工程师--->中级工程师--->高级工程师--->资深专家--->架构师

#golang的zk客户端 最近打算写个简单的配置中心，考虑到实现便捷性，语言选择了go，由于其中计划用到zk，就调研了下golang的zk客户端，并实现了个简单的分布式server。最终找到了两个，地址如下： gozk： https://wiki.ubuntu.com/gozk go-zookeeper： https://github.com/samuel/go-zookeeper 由于gozk的文档不如后者，且代码没在gihub上，所以就直接选择了后者。go-zookeeper文档还是比较全面的： 文档 #基本操作测试 这里默认大家已经了解zk的用处和基本用法了，如果还不了解可以参看： 官方文档 或 中文文档 下边我们先来写个简单的例子来测试下基本的操作： package main /** 客户端doc地址：github.com/samuel/go-zookeeper/zk **/ import ( "fmt" zk "github.com/samuel/go-zookeeper/zk" "time" ) /** * 获取一个zk连接 * @return {[type]} */ func getConnect(zkList []string) (conn *zk.Conn) { conn, _, err := zk.Connect(zkList, 10*time.Second)

简介 Apache Kafka 是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。 Apache Kafka与传统消息系统相比，有以下不同： 它被设计为一个分布式系统，易于向外扩展； 它同时为发布和订阅提供高吞吐量； 它支持多订阅者，当失败时能自动平衡消费者； 它将消息持久化到磁盘，因此可用于批量消费，例如 ETL ，以及实时应用程序。 本文我将重点介绍Apache Kafka的架构、特性和特点，帮助我们理解Kafka为何比传统消息服务更好。 我将比较Kafak和传统消息服务 RabbitMQ 、Apache ActiveMQ 的特点，讨论一些Kafka优于传统消息服务的场景。在最后一节，我们将探讨一个进行中的示例应用，展示Kafka作为消息服务器的用途。这个示例应用的完整源代码在 GitHub 。关于它的详细讨论在本文的最后一节。 架构 首先，我介绍一下Kafka的基本概念。它的架构包括以下组件： 话题（Topic） 是特定类型的 消息 流。 消息 是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。 生产者（Producer） 是能够发布消息到话题的任何对象。 已发布的消息保存在一组服务器中，它们被称为 代理（Broker

3 月，跳不动了？>>> Tachyon 0.7.1伪分布式集群安装与测试: http://blog.csdn.net/stark_summer/article/details/48321605 从官方文档得知，Spark 1.4.x和Tachyon 0.6.4版本兼容，而最新版的Tachyon 0.7.1和Spark 1.5.x兼容，目前所用的Spark为1.4.1，tachyon为 0.7.1 tachyon 与 hdfs整合 修改tachyon-env.sh export TACHYON_UNDERFS_ADDRESS=hdfs://master:8020Dtachyon.data.folder=$TACHYON_UNDERFS_ADDRESS/tmp/tachyon/data12 上传文件到hdfs hadoop fs -put /home/cluster/data/test/bank/ /data/spark/ hadoop fs -ls /data/spark/bank/Found 3 items-rw-r--r-- 3 wangyue supergroup 4610348 2015-09-11 20:02 /data/spark/bank/bank-full.csv-rw-r--r-- 3 wangyue supergroup 3864 2015-09-11 20

一、安装准备 1、下载zookeeper-3.3.1， 地址： http://www.apache.org/dist/hadoop/zookeeper/zookeeper-3.3.1/ 2、JDK版本：jdk-6u20-linux-i586.bin 3、操作系统：Linux 4、默认前提是安装完hadoop 0.20.2版本： 192.168.3.131 namenode 192.168.3.132 datanode 192.168.3.133 datanode 二、操作步骤（默认在namenode上进行） 1、拷贝以上文件到Linux的“/usr/”目录下。同时新建目录“/zookeeper-3.3.1”。 2、安装JDK，此步省略... 3、解压zookeeper到/zookeeper-3.3.1目录下。tar -zxvf zookeeper-3.3.1.tar.gz -C / zookeeper-3.3.1 4、将“/zookeeper-3.3.1/conf”目录下zoo_sample.cfg修改名称为“zoo.cfg” 5、打开zoo.cfg文件，修改配置如下： dataDir=/usr/zookeeper-3.3.1/data dataLogDir=/usr/ zookeeper-3.3.1/log clientPort=2181 initLimit=10

1.Hadoop 操作： 1 ） 查看Hadoop 版本： 2 ）自动开启 Hadoop ： hm@hm-ubuntu:~$ start-all.sh 3 ）手动开启 Hadoop ： 2.HDFS 操作： 1 ）查看 HDFS 上的文件： hadoop dfs -ls / 等同于 hadoop fs -ls / 2 ）向 HDFS 上传文件： （1）使用put 命令： hadoop fs -put test.txt /home/fs-test.txt （ 2 ）使用 copyFromLocal 命令： hadoop fs -copyFromLocal 本地目录/本地文件 /HDFS目录/文件 3 ）从 HDFS 下载文件： hadoop fs -get /HDFS目录/文件 本地目录/文件 （1）拷贝单个文件： （ 2 ）拷贝整个目录： 红色方框选中的hadoop-hm 目录是之前我们在 core-site.xml 文件中配置的临时目录。红色椭圆选中的 home 是刚刚我们 congHDFS 下载的文件夹。 4 ）删除 HDFS 上的文件： hadoop fs -rmr /home/*.txt 5）HDFS 的更多命令： 3.MapReduce示例操作-统计字符 1 ）在 HDFS 上执行 jar 程序： hadoop jar hadoop-examples-1.1.2.jar

此文档针对初学者。 废话不多说，先上源码： http://git.oschina.net/alexgaoyh/Dubbo-parent http://git.oschina.net/alexgaoyh/Dubbo-parent/attach_files Maven项目，只需要注意下图中红色箭头标注的三个模块即可； Dubbo-api： API接口，被 Dubbo-test-provider(服务提供者)，Dubbo-test-consumer（服务消费者）依赖； Dubbo-api 模块没什么多说的，只是需要的interface接口和实体类……； Dubbo-test-consumer 模块同样没有什么多说的，讲服务提供者发布的接口依赖到项目中即可，注意 consumerAll.xml 即可。 Dubbo-test-provider: 服务提供者，Dubbo整合mybatis spring druid，实现事务控制，druid监控数据的log4j日志记录（sql输出）； 下图中，需要注意两个单元测试的文件， DemoTest.java 文件是用来本地进行单元测试使用的，确保对外发布的服务接口都通过单元测试； DemoDubboTest.java 文件是直接对外发布dubbo服务接口的，相关的方法通过单元测试整合，即可对外发布接口，发布接口之后，服务消费者即可进行相关业务操作； PS

在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素： 一致性( C onsistency) 可用性( A vailability) 分区容忍性( P artition tolerance) CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而 对于分布式数据系统，分区容忍性是基本要求 ，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。 当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到 最终一致性 即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。 最终一致性(eventually consistent) 对于一致性