Linux查看文件内容的5种方式

目录 1. more指令 —— 分页显示文件内容 2. less指令 —— 可以向前或向后查看文件内容 3. head指令 —— 查看文件开头的内容 4. tail指令 —— 显示文件尾部的内容 5. cat指令 —— 显示文件内容 1. more指令 —— 分页显示文件内容 more指令会以一页一页的形式显示文件内容，按空白键（space）显示下一页内容，按Enter键会显示下一行内容，按 b 键就会往回（back）一页显示，其基本用法如下： more    file1             查看文件file1的文件内容； more   -num   file2    查看文件file2的内容，一次显示num行； more   +num   file3   查看文件file3的内容，从第num行开始显示； 2. less指令 —— 可以向前或向后查看文件内容 less指令查看文件内容时可以向前或向后随意查看内容； less指令的基本用法为： less   file1    查看文件file1的内容； less   -m    file2     查看文件file2的内容，并在屏幕底部显示已显示内容的百分比； 按空格键显示下一屏的内容，按回车键显示下一行的内容； 按  U  向前滚动半页，按  Y   向前滚动一行； 按[PageDown]向下翻动一页，按[PageUp]向上翻动一页； 按   Q   退出less命令； 3. head指令 —— 查看文件开头的内容 head指令用于显示文件开头的内容，默认情况下，只显示文件的头10行内容； head指令的基本用法： head  -n  <行数>   filename      显示文件内容的前n行； 例如：head   -n   5   file1     显示文件file1的前5行内容 […]

MariaDB 10.4.12 Stable Row size too large (> 8126). Changing some columns to TEXT or BLOB may help.

MariaDB 10.4.12 Stable# Row size too large (> 8126). Changing some columns to TEXT or BLOB may help.# 以下两步解决问题 1. 修改my.ini文件在[mysqld]下面加入下面三行#

  2. 新建一个查询进行如下操作将nombre_tabla改成你的表名#

    from:https://www.cnblogs.com/fanlinglong/p/12425116.html

搭建gitlab仓库

稍具规模一点的公司都会搭建属于自己的git，svn，而内部git用的最多的则是gitlab，虽然官网已经提供了非常多的功能，但内网搭建更能保证项目的私有性，只有公司内部员工才可以访问，更加安全。 这里演示gitlab的搭建与简单配置 操作 安装一些依赖软件包，SSH一般系统是默认安装好的，不过也不排除一些最小安装的系统没有sshd服务。

  关闭防火墙，或者开放HTTP的端口

  安装邮件服务，当gitlab想要通过邮件通知，也可以另外配置其它的邮件服务器

  从官网获取一件安装脚本，当然自己手动安装也是可以的gitlab下载地址，使用官网脚本会简单一些。执行这一步会如果使用CentOS系统，会添加gitlab的yum源

  安装gitlab

  上面已经安装好了gitlab，不过可以稍作一些配置，配置gitlab监听的地址与端口，gitlab的配置文件在/etc/gitlab/目录下，主要配置文件为gitlab.rb我修改了下gitlab.rb文件中的nginx监听地址,

  里面的配置项非常的多，可以对照官网文档根据需要修改。gitlab配置选项 运行gitlab命名，并重启

  打开浏览器查看效果,第一次打开页面会让我们设置root用户的密码。记住自己设置的密码，再次刷新进入登录页面   以管理员身份登录，默认的用户是root，密码是刚才设置的。 搭建好环境之后，下面的则根据官方文档解释，自己摸索做一些根据自己需要的修改，二次开发也可以。   最后 公司内部一般都会搭建内部gitlab仓库，自己搭建下摸索着玩玩。   参考 gitlab下载地址 gitlab配置选项   作者：Real_man 链接：https://www.jianshu.com/p/ade38a53b1ac 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

CentOS postfix启动报错net_interfaces: no local interface

CentOS 7 postfix启动报错： inet_interfaces: no local interface found for ::1 当前环境CentOS 7.4 [root@test ~]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) [root@test ~]# uname -r 3.10.0-693.2.2.el7.x86_64 使用systemctl start postfix时，总是提示： Job for postfix.service failed because the control process exited with error code. See “systemctl status postfix.service” and “journalctl -xe” for details. 重启也无效，查看日志more /var/log/maillog 或者 more /var/log/message 发现日志有报错信息： postfix: fatal: parameter inet_interfaces: no local interface found for ::1 重启服务器也没有解决 解决方法： vi /etc/postfix/main.cf 发现配置为： inet_interfaces = localhost inet_protocols = all 改成： inet_interfaces = all 或者 inet_interfaces = 127.0.0.1 inet_protocols = all […]

springboot(八) 开启热部署之Idea&Gradle

一、引入starter

  二、开启自动编译 第一步

  弹出以下界面   第二步 点击Registry,勾选compiler.automake.allow.when.app.running   第三步 勾选 Make/Build project automatically 重新运行项目，随意改一个java类，看看项目是不是重启了^_^   from:https://blog.csdn.net/JonWu0102/article/details/81064776

Gradle依赖排除

在引用依赖时经常会有这样的问题：某些间接引用的依赖项是不需要的；产生了依赖冲突。此时需要排除一些依赖。 下面的内容介绍了几种在gradle中排除依赖的方式。 在dependency中排除     1 2 3 4 5 6 7 8 dependencies { compile('com.zhyea:ar4j:1.0') { //excluding a particular transitive dependency: exclude module: 'cglib' //by artifact name exclude group: 'org.jmock' //by group exclude group: 'org.unwanted', module: 'iAmBuggy' //by both name and group } } 这种方式是粒度最细的，也是最为繁琐的。此时可以考虑全局设置。 在全局配置中排除 全局配置是在configuration中完成的。   1 2 3 4 configurations { compile.exclude module: 'cglib' all*.exclude group:’org.unwanted', module: 'iAmBuggy' }   禁用传递依赖 禁用传递依赖需要将属性transitive设置为false。可以在dependency中禁用传递依赖，也可以在configuration中全局禁用：   1 2 3 4 5 6 7 compile('com.zhyea:ar4j:1.0') { transitive = false }   configurations.all { transitive = false } 还可以在单个依赖项中使用@jar标识符忽略传递依赖： […]

Spring Boot 之 使用jetty web容器

springboot 中默认的web容器是tomcat。 在maven 的pom 文件中加入如下依赖，便可使用tomcat 容器。

  如果想使用 jetty 作为 web容器，需要2步操作： 1.排除默认的tomcat 容器

  2.加入 jetty 的 starter 依赖

  from:https://www.cnblogs.com/appleat/p/9100822.html

Webflux快速入门

SpringWebflux是SpringFramework5.0添加的新功能，WebFlux本身追随当下最火的Reactive Programming而诞生的框架，那么本篇就来简述一下这个框架到底是做什么的 一、关于WebFlux 我们知道传统的Web框架，比如说：struts2，springmvc等都是基于Servlet API与Servlet容器基础之上运行的，在Servlet3.1之后才有了异步非阻塞的支持。而WebFlux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说，它可以运行在诸如Netty，Undertow及支持Servlet3.1的容器上，因此它的运行环境的可选择行要比传统web框架多的多。 根据官方的说法，webflux主要在如下两方面体现出独有的优势： 1）非阻塞式 其实在servlet3.1提供了非阻塞的API，WebFlux提供了一种比其更完美的解决方案。使用非阻塞的方式可以利用较小的线程或硬件资源来处理并发进而提高其可伸缩性 2) 函数式编程端点 　　　　老生常谈的编程方式了，Spring5必须让你使用java8，那么函数式编程就是java8重要的特点之一，而WebFlux支持函数式编程来定义路由端点处理请求。   二、SpringMVC与SpringWebFlux 我们先来看官网的一张图： 它们都可以用注解式编程模型，都可以运行在tomcat，jetty，undertow等servlet容器当中。但是SpringMVC采用命令式编程方式，代码一句一句的执行，这样更有利于理解与调试，而WebFlux则是基于异步响应式编程，对于初次接触的码农们来说会不习惯。对于这两种框架官方给出的建议是： 1）如果原先使用用SpringMVC好好的话，则没必要迁移。因为命令式编程是编写、理解和调试代码的最简单方法。因为老项目的类库与代码都是基于阻塞式的。 2）如果你的团队打算使用非阻塞式web框架，WebFlux确实是一个可考虑的技术路线，而且它支持类似于SpringMvc的Annotation的方式实现编程模式，也可以在微服务架构中让WebMvc与WebFlux共用Controller，切换使用的成本相当小 3）在SpringMVC项目里如果需要调用远程服务的话，你不妨考虑一下使用WebClient，而且方法的返回值可以考虑使用Reactive Type类型的，当每个调用的延迟时间越长，或者调用之间的相互依赖程度越高，其好处就越大 我个人意见是：官网明确指出，SpringWebFlux并不是让你的程序运行的更快(相对于SpringMVC来说)，而是在有限的资源下提高系统的伸缩性，因此当你对响应式编程非常熟练的情况下并将其应用于新的系统中，还是值得考虑的，否则还是老老实实的使用WebMVC吧   三、Reactive Spring Web 在这里定义了最基本的服务端接口：HttpHandler和WebHandler 　　HttpHandler HttpHandler定义了最基本的处理Http请求行为，这个接口主要作用是处理Http请求并将结果做出响应，下面这个表格是说明了Server API的使用方式及何种方式进行响应式流支持的： Server name Server API used Reactive Streams support Netty Netty API Reactor Netty Undertow Undertow API spring-web: Undertow to Reactive Streams bridge Tomcat Servlet 3.1 non-blocking I/O; Tomcat API to read and write ByteBuffers vs byte[] spring-web: Servlet 3.1 non-blocking I/O to Reactive Streams bridge Jetty Servlet 3.1 non-blocking I/O; Jetty API to write ByteBuffers vs byte[] spring-web: Servlet 3.1 […]

soul极简入门

目录： 1. 概述 2. 单机部署 3. 接入 Dubbo 应用 4. 接入 Spring Boot 应用 5. 接入 Spring Cloud 应用 6. rateLimiter 插件 7. hystrix 插件 666. 彩蛋 作者：芋道源码 原文地址 大家好，我是艿艿，一个永远 18 岁的技术宅 1. 概述 Soul 是基于 WebFlux 实现的响应式的 API 网关，具有异步、高性能、跨语言等特点。 作者：我希望能够有一样东西像灵魂一样，保护您的微服务。在参考了 Kong、Spring Cloud Gateway 等优秀的网关后，站在巨人的肩膀上，Soul 由此诞生！ 作者是艿艿的大表弟，胖友信么？！ 目前 Soul 功能列表如下： 支持各种语言，无缝集成到 Dubbo、Spring Cloud、Spring Boot 中。 Soul 是极其少支持 Dubbo 的 API 网关，通过 Dubbo 泛化调用 实现。 支持各种语言(http协议)，支持 dubbo，springcloud协议。 插件化设计思想，插件热插拔,易扩展。 灵活的流量筛选，能满足各种流量控制。 内置丰富的插件支持，鉴权，限流，熔断，防火墙等等。 流量配置动态化，性能极高，网关消耗在 1~2ms。 支持集群部署，支持 A/B Test, 蓝绿发布。 整体架构如下图所示： 是不是看着就贼酷炫，实际一脸懵逼。不要慌~我们先来搭建 Soul 网关。 2. 单机部署 本小节，我们来单机部署一个 Soul 服务，适合测试环境。如下图所示： 2.1 MySQL 安装 相信大家都会，艿艿就不瞎哔哔了。嘿嘿~注意，目前最好安装 5.X 版本，艿艿一开始用 8.X 存在报错的情况。 安装完成后，创建 soul 数据库。 2.2 Soul Admin […]

TCC和两阶段提交

经常在网络上看见有人介绍TCC时，都提一句，”TCC是两阶段提交的一种”。其理由是TCC将业务逻辑分成try、confirm/cancel在两个不同的阶段中执行。其实这个说法，是不正确的。可能是因为既不太了解两阶段提交机制、也不太了解TCC机制的缘故，于是将两阶段提交机制的prepare、commit两个事务提交阶段和TCC机制的try、confirm/cancel两个业务执行阶段互相混淆，才有了这种说法。 两阶段提交（Two Phase Commit，下文简称2PC），简单的说，是将事务的提交操作分成了prepare、commit两个阶段。其事务处理方式为： 1、 在全局事务决定提交时，a）逐个向RM发送prepare请求；b）若所有RM都返回OK，则逐个发送commit请求最终提交事务；否则，逐个发送rollback请求来回滚事务； 2、 在全局事务决定回滚时，直接逐个发送rollback请求即可，不必分阶段。 * 需要注意的是：2PC机制需要RM提供底层支持（一般是兼容XA），而TCC机制则不需要。 TCC（Try-Confirm-Cancel），则是将业务逻辑分成try、confirm/cancel两个阶段执行，具体介绍见TCC事务机制简介。其事务处理方式为： 1、 在全局事务决定提交时，调用与try业务逻辑相对应的confirm业务逻辑； 2、 在全局事务决定回滚时，调用与try业务逻辑相对应的cancel业务逻辑。 可见，TCC在事务处理方式上，是很简单的：要么调用confirm业务逻辑，要么调用cancel逻辑。这里为什么没有提到try业务逻辑呢？因为try逻辑与全局事务处理无关。 当讨论2PC时，我们只专注于事务处理阶段，因而只讨论prepare和commit，所以，可能很多人都忘了，使用2PC事务管理机制时也是有业务逻辑阶段的。正是因为业务逻辑的执行，发起了全局事务，这才有其后的事务处理阶段。实际上，使用2PC机制时————以提交为例————一个完整的事务生命周期是：begin -> 业务逻辑 -> prepare -> commit。 再看TCC，也不外乎如此。我们要发起全局事务，同样也必须通过执行一段业务逻辑来实现。该业务逻辑一来通过执行触发TCC全局事务的创建；二来也需要执行部分数据写操作；此外，还要通过执行来向TCC全局事务注册自己，以便后续TCC全局事务commit/rollback时回调其相应的confirm/cancel业务逻辑。所以，使用TCC机制时————以提交为例————一个完整的事务生命周期是：begin -> 业务逻辑(try业务) -> commit(comfirm业务)。 综上，我们可以从执行的阶段上将二者一一对应起来： 1、 2PC机制的业务阶段 等价于 TCC机制的try业务阶段； 2、 2PC机制的提交阶段（prepare & commit） 等价于 TCC机制的提交阶段（confirm）； 3、 2PC机制的回滚阶段（rollback） 等价于 TCC机制的回滚阶段（cancel）。 因此，可以看出，虽然TCC机制中有两个阶段都存在业务逻辑的执行，但其中try业务阶段其实是与全局事务处理无关的。认清了这一点，当我们再比较TCC和2PC时，就会很容易地发现，TCC不是两阶段提交，而只是它对事务的提交/回滚是通过执行一段confirm/cancel业务逻辑来实现，仅此而已。     参考博客： 1. https://blog.csdn.net/Paranoia_ZK/article/details/79481976#commentsedit  TCC和两阶段分布式事务处理的区别 2. https://blog.csdn.net/Saintyyu/article/details/100822735 X/Open DTP模型与XA协议之我见 3、https://blog.csdn.net/Saintyyu/article/details/101054542 分布式事务的七种实现方案汇总分析   from:https://blog.csdn.net/Saintyyu/article/details/100862449