master

CentOS 6.5下Git服务器搭建

十年热恋 提交于 2020-01-08 19:37:38
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1 关于版本控制 版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。有以下三种版本控制系统: 1. 本地版本控制系统 许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少:有时候会混淆所在的工作目录,一旦弄错文件丢了数据就没法撤销恢复。 为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更新差异。图示如下, 2. 集中化的版本控制系统 集中化的版本控制系统( Centralized Version Control Systems,简称 CVCS )能够让在不同的开发系统上的开发人员协同工作。这类系统,诸如 CVS,Subversion 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法 3. 分布式版本控制系统 分布式版本控制系统(Distributed Version Control System,简称 DVCS ),像 Git,Mercurial,Bazaar 以及 Darcs 等

kubernetes集群部署DashBoard

会有一股神秘感。 提交于 2020-01-08 19:13:11
搭建K8s DashBoard 集群结构: 类型 主机名 ip Master k8s_master 192.168.3.216 Node k8s_client1 192.168.3.217 Node k8s_client2 192.168.3.219 以下操作都在k8s_master上执行: 一、镜像下载 [root@k8s_master ~]# docker pull docker.io/siriuszg/kubernetes-dashboard-amd64:v1.5.1 Trying to pull repository docker.io/siriuszg/kubernetes-dashboard-amd64 ... sha256:d0aebe2567a6b11d090403746f63df9dccd32aec9192decfd3794b0cce528930: Pulling from docker.io/siriuszg/kubernetes-dashboard-amd64 9d25d3817204: Pull complete Digest: sha256:d0aebe2567a6b11d090403746f63df9dccd32aec9192decfd3794b0cce528930 Status: Downloaded newer image for docker.io

分布式缓存之Redis

和自甴很熟 提交于 2020-01-08 15:49:12
缓存大致可以分为两类,一种是应用内缓存,比如Map(简单的数据结构),以及EH Cache(Java第三方库),另一种 就是缓存组件,比如Memached,Redis;Redis(remote dictionary server)是一个基于KEY-VALUE的高性能的 存储系统,通过提供多种键值数据类型来适应不同场景下的缓存与存储需求 存储结构 大家一定对字典类型的数据结构非常熟悉,比如map ,通过key value的方式存储的结构。 redis的全称是remote dictionary server(远程字典服务器),它以字典结构存储数据,并允许其他应用通过TCP协议读写字典中的内容。数 据结构如下 启动停止redis Redis有哪些可执行文件 Redis-server Redis服务器 Redis-cli Redis命令行客户端 Redis-benchmark          Redis性能测试工具 Redis-check-aof Aof文件修复工具 Redis-check-dump Rdb文件检查工具 Redis-sentinel Sentinel服务器(2.8以后) 常用的命令是redis-server和redis-cli \1.直接启动 redis-server ../redis.conf 服务器启动后默认使用的是6379的端口,通过--port可以自定义端口;

分离头指针(detached HEAD)

余生颓废 提交于 2020-01-08 11:58:10
通常,我们工作在某一个分支上,比如 master 分支。这个时候 master 指针和 HEAD 指针是一起前进的,每做一次提交,这两个指针就会一起向前挪一步。但是在某种情况下(例如 checkout 了某个具体的 commit),master 指针 和 HEAD 指针这种「绑定」的状态就被打破了,变成了分离头指针状态。我那天遇到的情况是,master 和 HEAD 指针看上去指在同一个 commit 上,但其实已经处在分离头指针状态。当我在此时又做了一次新的提交时,HEAD 指针跑到 master 指针前面去了。如果我直接检出 master 分支,HEAD 指针就会回退一格到 master 指针的位置,而最新的那次提交就变成了孤立的提交,没有任何分支能追踪到它,刚才的活白干了。 # 强制将 master 分支指向当前头指针的位置 $ git branch -f master HEAD # 检出 master 分支 $ git checkout master 参考:https://blog.csdn.net/qq_40718168/article/details/89521028 来源: https://www.cnblogs.com/ch122633/p/12165146.html

Redis高可用

南楼画角 提交于 2020-01-08 10:56:26
https://www.cnblogs.com/bingshu/p/9776610.html Redis高可用概述 在 Web 服务器中, 高可用 是指服务器可以 正常访问 的时间,衡量的标准是在 多长时间 内可以提供正常服务( 99.9% 、 99.99% 、 99.999% 等等)。 在 Redis 层面, 高可用 的含义要宽泛一些,除了保证提供 正常服务 (如 主从分离 、 快速容灾技术 等),还需要考虑 数据容量扩展 、 数据安全 等等。 在 Redis 中,实现 高可用 的技术主要包括 持久化 、 复制 、 哨兵 和 集群 ,下面简单说明它们的作用,以及解决了什么样的问题: 持久化 :持久化是 最简单的 高可用方法。它的主要作用是 数据备份 ,即将数据存储在 硬盘 ,保证数据不会因进程退出而丢失。 复制 :复制是高可用 Redis 的基础, 哨兵 和 集群 都是在 复制基础 上实现高可用的。复制主要实现了数据的 多机备份 以及对于 读操作的负载均衡 和 简单的故障恢复 。缺陷是 故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。 哨兵 :在复制的基础上,哨兵实现了 自动化 的 故障恢复 。缺陷是 写操作 无法 负载均衡 , 存储能力 受到 单机 的限制。 集群 :通过集群, Redis 解决了 写操作 无法 负载均衡 以及 存储能力 受到 单机限制 的问题

Redis for python API

心已入冬 提交于 2020-01-08 10:50:20
目录 Redis for python API 1、单实例 2、主从环境(哨兵) 3、集群环境 我叫张贺,贪财好色。一名合格的LINUX运维工程师,专注于LINUX的学习和研究,曾负责某中型企业的网站运维工作,爱好佛学和跑步。 个人博客: 传送阵 笔者微信: zhanghe15069028807 ,非诚勿扰。 Redis for python API 我们使用Redis一方面是为了缓存,另一个方面还是让开发人员使用,这一小节我们就演示一下用当下最火的语言python连接redis,其它的语言思路都与此类似。 不同的redis架构连接方法不一样,我们最常用的redis架构有三种:单实例、主从、集群。此次演示基于已经搭建好的环境,也就是前几次博文搭建的环境,具体的搭建过程不再多说,直奔主题。 redis和python是两套不相干的软件,想要联动起来的话必须要通过特殊的中间件,这种中间件类似于驱动程序,这种驱动程序在python官网和redis官网都可以下载的到。 redis官网:www.redis.io www.redis.cn 我们在使用python与redis联动时,最好使用python比较新的版本,3.0以上,就不要再用2.0的版本了,2.0的版本对redis集群的支持并不太好,在centos上安装python3也相当的简单,配置好epel源或是阿里云的源之后直接 yum

Git常用命令及场景

末鹿安然 提交于 2020-01-08 10:15:51
Git命令推送到远程分支 1、登录GitHub创建一个远程仓库。    https://github.com                2、git init   本地创建一个目录,并初始化一个git仓库。 3、git add   添加文件到当前目录下,然后执行git add ,将“修改”从当前工作区存放到暂存区。 4、git commit -m "注释语句"   将暂存区中存放的文件提交到本地git仓库。 5、git remote add origin https://远程仓库地址   将本地代码库的当前分支与远程的代码库分支相关联。 6、git pull origin master   远程库分支更新代码到本地。 7、git push -u origin master(远程分支)   将本地代码库的当前分支推送到远程的代码库。 如果如下报错 failed to push some refs to 'https://github.com/kosamino/demo.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint

敏捷开发流程之Scrum:3个角色、5个会议、12原则

…衆ロ難τιáo~ 提交于 2020-01-08 09:05:53
摘自: https://www.cnblogs.com/yixinjishu/p/12161359.html 敏捷开发流程之Scrum:3个角色、5个会议、12原则 本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。 一、Scrum的定义和目的 Scrum是一个用于开发和维护复杂产品的框架,是一个增量的、迭代的开发过程,目的是让开发人员像打橄榄球一样迅猛并充满激情,通过团队合作,提高工作效率。通过团队间的有效交互,为企业创造价值。 二、敏捷宣言 其实,在发表《敏捷宣言》之前,很多的敏捷实践都已经存在且使用了,比如:Scrum、XP、KanBan等。之所以发表《敏捷宣言》,是因为这些实践都是在单打独斗地推进敏捷开发,而不是以一个联合体的形式,且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》,共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话: 三、Scrum中的人员角色 3个角色 Scrum中的人员分为3个角色:产品所有者(Product Owner), Scrum Master,开发团队(Team)。 产品所有者:定义所有产品功能,决定产品发布的内容以及日期,对产品的投入产出负责,根据市场变化对需要开发的功能排列优先顺序,合理地调整产品功能和迭代顺序

day80

我的梦境 提交于 2020-01-08 02:09:40
目录 线下线上仓库初始化 仓库间通信要分支同步 协同开发版本冲突问题(重点) 远程仓库回滚 远程仓库合并分支 腾讯云短信服务 短信功能不封装 短信功能的二次封装 多方式登录 视图层 序列化 验证码发送 视图层 const.py 手机登录 视图层 序列化 复习 线下线上仓库初始化 流程: cd luffy/luffyapi git remote git remote -v git push online(自定义) master 然后去码云上随便新建一个xyz仓库,复制粘贴SSH公钥到git命令窗口中 git push xyz master git remote remove xyz (删除线上的仓库) git remote -v 桌面新建文件temp cd temp/ git clone 线上公钥SSH链接(可以克隆到temp文件夹中) cd xyz/ 赋值代码文件到xyz中 git add . git commit -m '初始化' git push xyz master git status git remote -v git push origin master 仓库间通信要分支同步 流程: 桌面新建proj文件夹 cd proj/ git clone 线上公钥SSH链接(可以克隆到temp文件夹中) 新建一个文件temp.txt git status cd luffyapi/

Replication Lag 的mysql 如何分析

旧街凉风 提交于 2020-01-07 22:57:10
转 https://blogs.oracle.com/jsmyth/what-causes-replication-lag What Causes Replication Lag? Mark Lewin MYSQL CURRICULUM DEVELOPER Replication lag occurs when the slaves (or secondaries ) cannot keep up with the updates occuring on the master (or primary ). Unapplied changes accumulate in the slaves' relay logs and the version of the database on the slaves becomes increasingly different from that of the master. To work out what's causing the lag, you must determine which replication thread is getting backed up. Replication relies on three threads per master/slave connection: one is created on