master

HBase集群环境配置 一、集群规划 二、前置条件 三、集群搭建 3.1 下载并解压 3.2 配置环境变量 3.3 集群配置 3.4 HDFS客户端配置 3.5 安装包分发 四、启动集群 4.1 启动ZooKeeper集群 4.2 启动Hadoop集群 4.3 启动HBase集群 4.5 查看服务 一、集群规划 这里搭建一个 3 节点的 HBase 集群，其中三台主机上均为 Regin Server 。同时为了保证高可用，除了在 hadoop001 上部署主 Master 服务外，还在 hadoop002 上部署备用的 Master 服务。Master 服务由 Zookeeper 集群进行协调管理，如果主 Master 不可用，则备用 Master 会成为新的主 Master 。 二、前置条件 HBase 的运行需要依赖 Hadoop 和 JDK( HBase 2.0+ 对应 JDK 1.8+ ) 。同时为了保证高可用，这里我们不采用 HBase 内置的 Zookeeper 服务，而采用外置的 Zookeeper 集群。相关搭建步骤可以参阅： Linux 环境下 JDK 安装 Zookeeper 单机环境和集群环境搭建 Hadoop 集群环境搭建 三、集群搭建 3.1 下载并解压 下载并解压，这里我下载的是 CDH 版本 HBase，下载地址为：http://archive

1 Git历史 同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002 年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。 到 2005 年的时候，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统订了若干目标： • 速度 • 简单的设计 • 对非线性开发模式的强力支持（允许上千个并行开发的分支） • 完全分布式 • 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量） 2Git与svn对比 2.1Svn SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就郁闷了。

登陆一个Git的托管服务器，这里我使用的是自己搭建的gitlab。然后创建一个账号，新建一个仓库。下载git客户端。 配置 12 git config --global user.name "your name"git config --global user.email "your email" 生成SSH kEY 1 ssh-keygen -t rsa -C "your.email@example.com" -b 4096 连续回车三次 1 cat ~/.ssh/id_rsa.pub 复制密钥。然后去git服务器添加到你的用户设置里面，就可以直接使用ssh认证方式，而不需要每次输入用户名密码。 新建仓库 1.本地已经存在工程 登陆git服务器，创建远程仓库（test）。然后打开git bash客户端。 123456 cd basedirgit init git remote add origin git@192.168.16.100:liurui/test.gitgit add .git commit -m "Initial commit"git push -u origin master 2.创建新的仓库 123456 git clone git@192.168.16.100:liurui/test.gitcd testtouch README.mdgit add

1.git介绍 1.1 什么是git？ 什么是Git? 比如一个项目，两个人同时参与开发，那么就把这个项目放在一个 公共的地方 ，需要的时候都可以去获取，有什么改动，都可以进行提交。 为了做到这一点，就需要一个版本控制系统，Git就是这样一个免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。 1.2 提供git的网站 提供git服务的网站有很多 国外常用的是: http://github.com 国内常用的是码云： http://git.oschina.net github慢，但是上面内容多，大神多，简历里也需要github.com 码云快，但是内容少 1.3 git分支介绍 master分支，即主分支。 任何项目都必须有个这个分支。对项目进行tag或发布版本等操作，都必须在该分支上进行。 develop分支，即开发分支，从master分支上检出。 团队成员一般不会直接更改该分支，而是分别从该分支检出自己的feature分支，开发完成后将feature分支上的改动merge回develop分支。同时release分支由此分支检出。 release分支，即发布分支，从develop分支上检出。 该分支用作发版前的测试，可进行简单的bug修复。如果bug修复比较复杂，可merge回develop分支后由其他分支进行bug修复。此分支测试完成后

Redis 之集群高可用和安全控制 一、 Redis 的主从复制 1.1. 为什么使用主从 单个 Redis 如果因为某种原因宕机的话，可能会导致 Redis 服务不可用，可以使用主从复制实现一主多从，主节点负责写的操作，从节点负责读的操作，主节点会定期将数据同步到从节点中，保证数据一致性的问题。 1.2. 主从的方式 最少需要3个节点。 第一种： 第二种： 优先选择第二种，第一种方式主节点向从节点同步数据压力大。 1.3. 主从复制配置： 将编译之后的 Redis 中的 bin 目录中全部内容 角色 端口 配置文件 主节点 6379 redis_6379.conf 从节点 6380 redis_6380.conf 从节点 6381 redis_6381.conf 从节点 6382 redis_6382.conf 相关目录结构 内存有限，我们只模拟不同端口下的 Redis 主从复制。我模拟了一主三从，采用树状结构： 核心配置：主节点 # ip监控 bind 0.0.0.0 protected-mode no # requirepass 123456 # 端口 port 6379 # 后台运行 daemonize yes # 工作目录 dir ./ # pid pidfile "/var/run/redis_6379.pid" # 日志名 logfile "redis_6379

1、使用redis有哪些好处？ 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1) 支持丰富数据类型，支持string，list，set，sorted set，hash 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除 2、redis相比memcached有哪些优势？ memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型 redis的速度比memcached快很多 redis可以持久化其数据 3、redis常见性能问题和解决方案： Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内 尽量避免在压力很大的主库上增加从库 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3... 这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。 4、redis

创建一个http应用程序 1)创建一个应用程序，我们使用 "kubectl run " 命令，是 “kubectl run -h” 查看命令使用帮助，命令说明告诉我们这个命令可以创建一个deployment或者job的容器(deployment和job是什么意思，我们后续再讲) [root@master ~]# kubectl run nginx-deploy --image=nginx --port=80 kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. deployment.apps/nginx-deploy created [root@master ~]# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE httpd-app 2/2 2 2 6m51s nginx-deploy 1/1 1 1 8s [root@master ~]# kubectl get deployment -o wide NAME READY UP-TO-DATE