Welcome to sukbear's Blog!
Talk is cheap, Show me the code-
Linux
Linux
- 在Linux操作系统中，所有被操作系统管理的资源，例如网络接口卡、磁盘驱动器、打印机、输入输出设备、普通文件或是目录都被看作是一个文件。也就是说在LINUX系统中有一个重要的概念：一切都是文件。
常见目录
- /bin： 存放二进制可执行文件(ls、cat、mkdir等)，常用命令一般都在这里；
- /etc： 存放系统管理和配置文件；
- /home： 存放所有用户文件的根目录，是用户主目录的基点，比如用户user的主目录就是/home/user，可以用~user表示；
- /usr ： 用于存放系统应用程序；
- /opt： 额外安装的可选应用程序包所放置的位置。一般情况下，我们可以把tomcat等都安装到这里；
- /proc： 虚拟文件系统目录，是系统内存的映射。可直接访问这个目录来获取系统信息；
- /root： 超级用户（系统管理员）的主目录（特权阶级^o^）；
- /sbin: 存放二进制可执行文件，只有root才能访问。这里存放的是系统管理员使用的系统级别的管理命令和程序。如ifconfig等；
- /dev： 用于存放设备文件；
- /mnt： 系统管理员安装临时文件系统的安装点，系统提供这个目录是让用户临时挂载其他的文件系统；
- /boot： 存放用于系统引导时使用的各种文件；
- /lib ： 存放着和系统运行相关的库文件 ；
- /tmp： 用于存放各种临时文件，是公用的临时文件存储点；
- /var： 用于存放运行时需要改变数据的文件，也是某些大文件的溢出区，比方说各种服务的日志文件（系统启动日志等。）等；
- /lost+found： 这个目录平时是空的，系统非正常关机而留下“无家可归”的文件（windows下叫什么.chk）就在这里。
终端常用快捷键
常用命令
- pwd：显示当前所在位置
- grep 要搜索的字符串 要搜索的文件 –color： 搜索命令，–color代表高亮显示
-
ps -ef ps -aux 当前系统正运行的进程 特定进程ps -aux grep redis - kill -9 进程的pid： 杀死进程（-9 表示强制终止）
- ifconfig 系统的网卡信息
- ping 机器连接情况
- netstat -an 系统端口使用
- reboot 重开机
端口占用
- lsof -i:端口号 用于查看某一端口的占用情况，比如查看8000端口使用情况，lsof -i:8000
-
netstat -tunlp grep 端口号，用于查看指定的端口号的进程情况，如查看8000端口的情况，netstat -tunlp grep 8000
目录与文件
权限
- 注意umask权限
目录
目录切换
cd usr： 切换到该目录下usr目录 cd ..（或cd../）： 切换到上一层目录 cd /： 切换到系统根目录 cd ~： 切换到用户主目录 cd -： 切换到上一个操作所在目录目录操作
mkdir 目录名称： 增加目录 ls或者ll 查看目录 find 目录 参数： 寻找目录/文件（查） mv 目录名称 新目录名称： 修改目录的名称（改） mv 目录名称 目录的新位置： 移动目录的位置---剪切（改） cp -r 目录名称 目录拷贝的目标位置： 拷贝目录（改），-r代表递归拷贝 rm -rf 目录文件
增
touch 文件名称: 文件的创建（增） cat/more/less/tail 文件名称 文件的查看（查） #### 查 cat： 查看显示文件内容 more： 可以显示百分比，回车可以向下一行， 空格可以向下一页，q可以退出查看 less： 可以使用键盘上的PgUp和PgDn向上 和向下翻页，q结束查看 tail-10 ： 查看文件的后10行，Ctrl+C结束 #### 删 rm -rf 文件： 删除文件（删） #### 解压缩 tar -zcvf 打包压缩后的文件名 要打包压缩的文件 tar -xvf 解压缩文件 #### 安装 yum rpm(源码包) gcc-> make make install ## Linux用户管理用户管理
useradd 选项 用户名:添加用户账号 userdel 选项 用户名:删除用户帐号 usermod 选项 用户名:修改帐号 passwd 用户名:更改或创建用户的密码 passwd -S 用户名 :显示用户账号密码信息 passwd -d 用户名: 清除用户密码用户组管理
groupadd 选项 用户组 :增加一个新的用户组 groupdel 用户组:要删除一个已有的用户组 groupmod 选项 用户组 : 修改用户组的属性vim
- insert（a i o）
- gg G 文件开头结尾
- 0 $ 行开头结尾
- dd 删除当前行 dG
shell
正则
程序逻辑参考其他语言，注意语法格式
-
管道 前一个结果作为后一个参数
-
消息队列
什么是消息队列？
- 消息队列比作是一个存放消息的容器，当我们需要使用消息的时候可以取出消息供自己使用。消息队列是分布式系统中重要的组件，使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。
使用消息队列的好处
- 通过异步处理提高系统性能（削峰、减少响应所需时间）
- 在不使用消息队列服务器的时候，用户的请求数据直接写入数据库，在高并发的情况下数据库压力剧增，使得响应速度变慢。但是在使用消息队列之后，用户的请求数据发送给消息队列之后立即 返回，再由消息队列的消费者进程从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度快于数据库（消息队列也比数据库有更好的伸缩性），因此响应速度得到大幅改善。
- 消息队列具有很好的削峰作用的功能——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。 举例：在电子商务一些秒杀、促销活动中，合理使用消息队列可以有效抵御促销活动刚开始大量订单涌入对系统的冲击。
- 降低系统耦合性 如果模块之间不存在直接调用，那么新增模块或者修改模块就对其他模块影响较小，这样系统的可扩展性无疑更好一些。 消息队列使利用发布-订阅模式工作，消息发送者（生产者）发布消息，一个或多个消息接受者（消费者）订阅消息。 消息发送者（生产者）和消息接受者（消费者）之间没有直接耦合，消息发送者将消息发送至分布式消息队列即结束对消息的处理，消息接受者从分布式消息队列获取该消息后进行后续处理，并不需要知道该消息从何而来。对新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统和业务没有任何影响，从而实现网站业务的可扩展性设计。 另外为了避免消息队列服务器宕机造成消息丢失，会将成功发送到消息队列的消息存储在消息生产者服务器上，等消息真正被消费者服务器处理后才删除消息。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中的其他服务器发布消息。
使用消息队列带来的问题
· 系统可用性降低： 系统可用性在某种程度上降低，为什么这样说呢？在加入MQ之前，你不用考虑消息丢失或者说MQ挂掉等等的情况，但是，引入MQ之后你就需要去考虑了！ · 系统复杂性提高： 加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！ · 一致性问题： 消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了!
常见MQ对比
对比方向 概要 吞吐量 万级的 ActiveMQ 和 RabbitMQ 的吞吐量（ActiveMQ 的性能最差）要比 十万级甚至是百万级的 RocketMQ 和 Kafka 低一个数量级。 可用性 都可以实现高可用。ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。RocketMQ 基于分布式架构。 kafka 也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 时效性 RabbitMQ 基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他三个都是 ms 级。 功能支持 除了 Kafka，其他三个功能都较为完备。 Kafka 功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 消息丢失 ActiveMQ 和 RabbitMQ 丢失的可能性非常低， RocketMQ 和 Kafka 理论上不会丢失。
-
Redis的List实现MQ
工具类
public class EventHandlerRedisUtil { public static void push(EventMessage message, String key) { ListRedisTemplate listRedisTemplate = SpringUtil.getBean(ListRedisTemplate.class); SetRedisTemplate setRedisTemplate = SpringUtil.getBean(SetRedisTemplate.class); String jsonStr = JSONArray.toJSONString(message); listRedisTemplate.lpush(key, jsonStr); setRedisTemplate.sadd(key, jsonStr); } }该工具类用于将消息事件push进Redis的List中，同时再将该消息事件保存在Set数据结构中，防止消息事件取出来的过程中突然重启导致消息事件丢失，由于Redis已做持久化处理，所以项目再次重会重新加载Set的消息到List中。
/** * 消息事件处理异步工具类 * Created by zch on 2017/9/6. */ public class EventHandlerAsyncUtil { private static ExecutorService executorService = null; public static void submit(Runnable runnable) { if(null == executorService) { executorService = Executors.newFixedThreadPool(300, new CustomizableThreadFactory("event-handler-async-pool-")); } executorService.submit(runnable); } }该工具类用于异步执行消息事件。
-
MySQL日志
MySQL 日志
· redo log //重做日志 · undo log //回滚日志 · bin log //二进制日志 · error log //错误日志 · slow queryl og //慢查询日志 · general log // 一般查询日志 · relay log //中继日志redo log
作用
- 确保事务的持久性。
- 防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
内容
物理格式的日志，记录的是物理数据页面的修改信息，是顺序写入 redo log file 中去的
开始写入时间
事务开始之后就开始写，而不是事务提交前。重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为8M，Innodb存储引擎先将重做日志写入innodb_log_buffer。
写入方式
- 通过以下三种方式将innodb日志缓冲区的日志刷新到磁盘 · 1，Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件。 · 2，每个事务提交时会将重做日志刷新到重做日志文件。 · 3，当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件 · 由此可以看出，重做日志通过不止一种方式写入到磁盘，尤其是对于第一种方式，Innodb_log_buffer到重做日志文件是Master Thread线程的定时任务。 因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。
undo log
作用
- 保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读
内容
逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。
产生时间
事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性
释放时间
当事务提交之后，undo log并不能立马被删除， 而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。
其他
undo是在事务开始之前保存的被修改数据的一个版本，产生undo日志的时候，同样会伴随类似于保护事务持久化机制的redolog的产生。 默认情况下undo文件是保持在共享表空间的，也即ibdatafile文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的undo信息，全部保存在共享表空间中的。 因此共享表空间可能会变的很大，默认情况下，也就是undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。 因此，mysql5.7之后的“独立undo 表空间”的配置就显得很有必要了。
bin log
作用
1，用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。 2，用于数据库的基于时间点的还原。内容
逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。 但又不完全是sql语句这么简单，而是包括了执行的sql语句（增删改）反向的信息， 也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后的版本的信息；insert对应着delete和insert本身的信息。 在使用mysqlbinlog解析binlog之后一些都会真相大白。 因此可以基于binlog做到类似于oracle的闪回功能，其实都是依赖于binlog中的日志记录。
产生时间
事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。 这里与redo log很明显的差异就是redo log并不一定是在事务提交的时候刷新到磁盘，redo log是在事务开始之后就开始逐步写入磁盘。 因此对于事务的提交，即便是较大的事务，提交（commit）都是很快的，但是在开启了bin_log的情况下，对于较大事务的提交，可能会变得比较慢一些。 这是因为binlog是在事务提交的时候一次性写入的造成的，这些可以通过测试验证。
释放时间
binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。
其他
- 二进制日志的作用之一是还原数据库的，这与redo log很类似，很多人混淆过，但是两者有本质的不同 1，作用不同：redo log是保证事务的持久性的，是事务层面的，binlog作为还原的功能，是数据库层面的（当然也可以精确到事务层面的），虽然都有还原的意思，但是其保护数据的层次是不一样的。 2，内容不同：redo log是物理日志，是数据页面的修改之后的物理记录，binlog是逻辑日志，可以简单认为记录的就是sql语句 3，另外，两者日志产生的时间，可以释放的时间，在可释放的情况下清理机制，都是完全不同的。 4，恢复数据时候的效率，基于物理日志的redo log恢复数据的效率要高于语句逻辑日志的binlog关于事务提交时，redo log和binlog的写入顺序，为了保证主从复制时候的主从一致（当然也包括使用binlog进行基于时间点还原的情况），是要严格一致的， MySQL通过两阶段提交过程来完成事务的一致性的，也即redo log和binlog的一致性的，理论上是先写redo log，再写binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成。
relay log
区别与联系
-
innodb引擎中的redo/undo log与mysql binlog是完全不同的日志，它们主要有以下几个区别：
· 1、层次不同，redo/undo 是indodb层维护的，而binlog是mysql server层维护的，跟采用何种引擎没有关系，记录的是所有引擎的更新操作的日志记录
· 2、记录内容不同，redo/undo记录的是每个页的修改情况，属于物理加逻辑的方式（redo log到物理页，页内采用逻辑日志，undo log采用的是逻辑日志），目的是保证数据的一致性，binlog记录的是事物操作内容，比如一条语句DELETE FROM TABLE WHERE i > 1之类的，不管采用的是什么引擎，当然格式是二进制的，要解析日志内容可以用这个命令mysqlbinlog -vv BINLOG。
· 3、记录时机不同，redo/undo在事物执行过程中会不断的写入，binlog是在事物最终commit前写入，binlog什么时候刷新到磁盘跟参数sync_binlog相关。
显然，我们执行SELECT等不涉及数据更新的语句是不会记binlog的，而涉及到数据更新则会记录。要注意的是，对支持事务的引擎如innodb而言，必须要提交了事务才会记录binlog。
binlog刷新到磁盘的时机跟sync_binlog参数息息相关，如果此参数配置为0，表示MySQL不控制binlog的刷新，则直接由文件系统决定什么时候刷新到磁盘，如果设置为不为0，则表示隔多少个事物刷新到磁盘，设置为1是最安全，在系统故障时最多丢失一个事务的更新，但是会对性能有所影响。一般情况下会设置为100或者0，牺牲一定的一致性来获取更好的性能。
-
Cloud Server
心路历程
- 利用maven 打包好项目 project.jar
- java -jar project.jar ( 启动失败，端口被占用，修改配置文件，再打包，再运行)
- 依旧失败，麻烦，查资料 直接终端指定运行端口
- 仍然失败，公网IP在ifconfig 无记录，无法直接访问公网ip
- 配置安全组，开放端口，将server拖进开放端口的安全组
- 配置域名与ip的映射
- 80端口被nginx占用，将占用80端口的进程杀死 kill -9 pid
- 启动项目 java -jar project.jar –server.port=80
- 问题？终端退出，项目结束。
- 再次启动项目 nohup java -jar project.jar –server.port=80
- 本地机器输入域名 可以访问项目
-
一个RPC框架—Dubbo
Dubbo
Dubbo是一款高性能、轻量级的开源Java RPC 框架,它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
Maven dependency
<properties> <dubbo.version>2.7.0</dubbo.version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-dependencies-bom</artifactId> <version>${dubbo.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo</artifactId> <version>${dubbo.version}</version> </dependency> <dependency> <groupId>io.netty</groupId> <artifactId>netty-all</artifactId> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> </dependency> </dependencies>RPC (Remote Procedure Call)
- 远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
- 服务消费方（client）调用以本地调用方式调用服务；
- client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
- client stub找到服务地址，并将消息发送到服务端；
- server stub收到消息后进行解码；
- server stub根据解码结果调用本地的服务；
- 本地服务执行并将结果返回给server stub；
- server stub将返回结果打包成消息并发送至消费方；
- client stub接收到消息，并进行解码；
- 服务消费方得到最终结果。
Dubbo架构
- Provider： 暴露服务的服务提供方
- Consumer： 调用远程服务的服务消费方
- Registry： 服务注册与发现的注册中心
- Monitor： 统计服务的调用次数和调用时间的监控中心
- Container： 服务运行容器
- 调用关系说明：
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
关系调用
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
工作原理
图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。- 各层说明： 第一层：service层，接口层，给服务提供者和消费者来实现的 第二层：config层，配置层，主要是对dubbo进行各种配置的 第三层：proxy层，服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton 第四层：registry层，服务注册层，负责服务的注册与发现 第五层：cluster层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务 第六层：monitor层，监控层，对rpc接口的调用次数和调用时间进行监控 第七层：protocol层，远程调用层，封装rpc调用 第八层：exchange层，信息交换层，封装请求响应模式，同步转异步 第九层：transport层，网络传输层，抽象mina和netty为统一接口 第十层：serialize层，数据序列化层。网络传输需要。
负载均衡策略
负载均衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动的的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用具有负载平衡而不是单个组件的多个组件可以通过冗余提高可靠性和可用性。负载平衡通常涉及专用软件或硬件 - Random LoadBalance(默认，基于权重的随机负载均衡机制) - 随机，按权重设置随机概率。 - 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。 - ConsistentHash LoadBalance - 一致性 Hash，相同参数的请求总是发到同一提供者。(如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。) - 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。zookeeper宕机与dubbo直连的情况
在实际生产中，假如zookeeper注册中心宕掉，一段时间内服务消费方还是能够调用提供方的服务的，实际上它使用的本地缓存进行通讯，这只是dubbo健壮性的一种提现。
- dubbo的健壮性表现：
- 监控中心宕掉不影响使用，只是丢失部分采样数据
- 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
- 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
- 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
- 服务提供者无状态，任意一台宕掉后，不影响使用
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
- 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。所以，我们可以完全可以绕过注册中心——采用 dubbo 直连 ，即在服务消费方配置服务提供方的位置信息。
- 远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。