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

终于有人把“TCC分布式事务”实现原理讲明白了！

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章：《拜托，面试请不要再问我Spring Cloud底层原理！》。 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring Cloud 开发这么一个微服务系统，很有可能会干出这种事儿来。 我们来看看下面的这个图，直观的表达了上述的过程： 所以说，我们有必要使用 TCC 分布式事务机制来保证各个服务形成一个整体性的事务。 上面那几个步骤，要么全部成功，如果任何一个服务的操作失败了，就全部一起回滚，撤销已经完成的操作。 比如说库存服务要是扣减库存失败了，那么订单服务就得撤销那个修改订单状态的操作，然后得停止执行增加积分和通知出库两个操作。 说了那么多，老规矩，给大家上一张图，大伙儿顺着图来直观的感受一下： 落地实现 TCC 分布式事务 那么现在到底要如何来实现一个 TCC 分布式事务，使得各个服务，要么一起成功？要么一起失败呢？ 大家稍安勿躁，我们这就来一步一步的分析一下。咱们就以一个 Spring Cloud 开发系统作为背景来解释。 TCC 实现阶段一：Try 首先，订单服务那儿，它的代码大致来说应该是这样子的：

如果你之前看过 Spring Cloud 架构原理那篇文章，同时对 Spring Cloud 有一定的了解的话，应该是可以理解上面那段代码的。 其实就是订单服务完成本地数据库操作之后，通过 Spring Cloud 的 Feign 来调用其他的各个服务罢了。 但是光是凭借这段代码，是不足以实现 TCC 分布式事务的啊？！兄弟们，别着急，我们对这个订单服务修改点儿代码好不好。 首先，上面那个订单服务先把自己的状态修改为：OrderStatus.UPDATING。 这是啥意思呢？也就是说，在 pay() 那个方法里，你别直接把订单状态修改为已支付啊！你先把订单状态修改为 UPDATING，也就是修改中的意思。 这个状态是个没有任何含义的这么一个状态，代表有人正在修改这个状态罢了。 然后呢，库存服务直接提供的那个 reduceStock() 接口里，也别直接扣减库存啊，你可以是冻结掉库存。 […]