master

目录 问题 问题 细心的同学会发现原来的Master恢复成Slave后，他的同步状态不OK，状态为master_link_status:down，这是为什么呢？ 这是因为我们只设置了Slave的masterauth，这是用于同步master的数据，但是Master一开始是不受影响的 当master转变为slave后，由于他没有设置masterauth，所以他不能从新的master同步数据 随之导致info replication的时候，同步状态为down，所以只需要修改redis.conf中的masterauth设置为自己的Redis即可 一般master数据无法同步给slave的方案检查为如下： 网络通信问题，要保证互相ping通，内网互通。 关闭防火墙，对应的端口开发（虚拟机中建议永久关闭防火墙，云服务器的话需要保证内网互通）。 统一所有的密码，不要漏了某个节点没有设置。 来源： CSDN 作者： Hereto. 链接： https://blog.csdn.net/kuangxie4668/article/details/104655127

目录 环境准备 引子 特点 集群容错 redis.conf 配置 启动6个redis实例 创建集群 检查集群信息 环境准备 引子 前面的章节我们讲了主从复制以及哨兵，他们可以提高读的并发 但是单个master容量有限，数据达到一定程度会有瓶颈，这个时候可以通过水平扩展为多master-slave成为集群。 这个时候就出现了redis-cluster：他可以支撑多个master-slave，支持海量数据，实现高可用与高并发。 哨兵模式其实也是一种集群，他能够提高读请求的并发 但是容错方面可能会有一些问题，比如master同步数据给slave的时候，这其实是异步复制吧 这个时候master挂了，那么slave上的数据就没有master新，数据同步需要时间的，1-2秒的数据会丢失 master恢复并转换成slave后，新数据则丢失。 特点 每个节点知道彼此之间的关系，也会知道自己的角色，当然他们也会知道自己存在与一个集群环境中，他们彼此之间可以交互和通信，比如ping pong。那么这些关系都会保存到某个配置文件中，每个节点都有，这个我们在搭建的时候会做配置的。 客户端要和集群建立连接的话，只需要和其中一个建立关系就行。 某个节点挂了，也是通过超过半数的节点来进行的检测，客观下线后主从切换，和我们之前在哨兵模式中提到的是一个道理。 Redis中存在很多的插槽，又可以称之为槽节点

CICD核心概念 CICD是持续集成（continuous integration，CI），持续交付（continuous delivery，CD），持续部署（continuous Deployment，CD）的简称。 指在开发过程中自动执行一系列脚本来减低开发引入bug的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。 1，持续集成 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处有两个： 1）快速发现错误：每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 2）防止分支大幅偏离主干：如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的： 让产品可以快速迭代同时还能保持高质量，它的核心措施是：代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。 Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。" 2， 持续交付 持续交付指的是频繁的将软件的新版本交付给质量团队或用户，以供评审，如果评审通过，代码就进入生产阶段。 持续交付可以看作是持续集成的下一步，强调的是，不管怎样更新，软件是随时随地可以交付的。 3，持续部署 持续部署是持续交付的下一步，指的是代码通过评审之后，自动部署到生产环境。 持续部署的目标是：代码在任何时候都是可以部署的

GIT&github入门 版本控制的原理： 根据md5进行文件的校验【MD5的特性就是每次的输入一致则输出也一致】，对于每次的修改进行一次快照 版本控制的2个功能： 版本管理 + 协作开发 什么是 GIT GIT因为最初是从Linux起家的，非常依赖文件系统的一些特性，这些在 Linux 下表现的很好，而 Windows 下特别糟糕Git 中文教程。 Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理. Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。 Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 最近就迁移到 Git 上来了，很多 Freedesktop 的项目也迁移到了 Git 上。【Linus在1991年创建了开源的Linux】 GitHub： · 一个拥有143万开发者的社区

1.将 当前dev 分支 合并到 master 分支: (1)切换到master 分支 点击 master 分支 .check out (2)选择local branches , 选择 自己的dev分支 ,点击 "merge" (3) git--> push 推送到 master 远程仓库 参考: https://blog.csdn.net/dling8/article/details/89049222 2. 将 master 分支 合并到自己的dev 分支: 在自己的分支下, 选择 remote branches 中的 origin/master 分支,点击 "merge into current" 参考: https://blog.csdn.net/weixin_40836179/article/details/87003899 https://blog.csdn.net/qq_35098526/article/details/79709571?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task 来源： CSDN 作者： 我如云影君如梦 链接： https://blog.csdn.net/qq_35043925/article

目录 第一章：创建合并分支 第二章：TortoiseGit实现分支管理 2.1-创建分支 2.2-合并分支 第三章：解决冲突 第四章：在IntelliJ IDEA中使用git 4.1-在Idea中配置git 4.2-将工程添加至git 4.3-从远程仓库克隆 4.4-从服务端拉取代码 git分支管理 在IntelliJ IDEA中使用git 第一章：创建合并分支 在我们每次的提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点： 每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。 当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上： 你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！ 不过，从现在开始，对工作区的修改和提交就是针对dev分支了

git分支管理 在IntelliJ IDEA中使用git 第一章：创建合并分支 在我们每次的提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD指针严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。 一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点： 每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。 当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上： 你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！ 不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变： 假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并： 所以Git合并分支也很快！就改改指针，工作区内容也不变！

https://sciter.com/sdk/doc.api/html/index.html sciter API文档2.F:\xindashen_study\sciter-sdk-master\demos.osx\layered最小化关闭例子位置3.F:\xindashen_study\sciter-sdk-master\samples\dialogs+windows 最小化关闭上图位置状态栏处理移动例子 F:\xindashen_study\sciter-sdk-master\samples\dialogs+windows\samples\sample-frame-window.htm 最大最小关闭操作 鼠标触发消息 +lib文件里面 静态图片变成动态图处理 +micro-charts F:\xindashen_study\sciter-sdk-master\samples\+vlist\demos\test-table-multiselect.htm 表控件操作模板 F:\xindashen_study\sciter-sdk-master\samples\alice=db-virtual-list-notifications 右下角弹窗 F:\xindashen_study\sciter-sdk-master\samples\basics 鼠标操作 sdk/samples

前言 　　使用集群是大中型网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求和用户量。这种情况下，更恰当的做法是增加一台或多台服务器去分担原有服务器的访问及存储压力。通过 负载均衡调度服务器，将来自浏览器的访问请求分发到应用服务器集群中的任何一台服务器上 ，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。 环境准备 　　192.168.0.221：nginx + keepalived master (主) 　　192.168.0.222：nginx + keepalived backup slave (从) 　　192.168.0.223：tomcat 　　192.168.0.224：tomcat 　　虚拟ip(VIP):192.168.0.200，对外提供服务的ip，也可称作浮动ip 　　各个组件之间的关系图如下： Tomcat做应用服务器 　　 tomcat 的安装不在本博客范围之内，具体例子网上很多在此就不讲解， tomcat 的 webapps 下记得放自己的应用，我的是 myWeb ，如果大家也用我的 myWeb ，那么index.jsp中的ip需要换成自己的 　　将192.168.0.223

Git相关知识 一台电脑上同时配置gitlab和gitHub（分别需要不同账号） Git常用的操作命令（个人常用） Git忽略提交（.gitignore） 1.一台电脑上同时配置gitlab和gitHub 这里我假定你已经配好了gitlab账号，因为在公司用的都是gitlab，gitHub是在空余时间自己配置的。 如果还没有配置过的同学可以参考下面这篇文章来配置，就不一一叙述了。 https://www.jianshu.com/p/6e1de95828a8 1.首先是生成密钥，任意地方git bash 然后输入 $ ssh - keygen - t rsa - C "注册的gitHub邮箱" 因为我已经存在密钥了所以才有这个提示，我是放在C盘里（默认就是C盘），各位自行选择位置就好。 2.创建config文件 在上一步做完之后直接cd ~/.ssh 进入该目录创建config文件 创建config文件 touch config 检查当前目录下的文件 ls 然后编辑config文件 vim config 输入i进入编辑模式 编辑一下内容 Host gitlab HostName gitlab . com User 你的gitlab用户名 IdentityFile ~ / . ssh / id_rsa Host github HostName github . com User