react native搭建环境，安装homebrew的时候，在终端输入 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 提示： curl: (7) Failed to connect to raw.githubusercontent.com port 443: Operation 解决方法： 这个是stackoverflow的解决方法，英文的，我翻译了一下 我的翻译： 先在浏览器输入这个地址： https://raw.githubusercontent.com/Homebrew/install/master/install 看是否能打开，不能打开就是你网络有问题，不要问我哦。 能打开如下： 把这个网页保存名为brew_install.rb的文件，保存的位置你随便，只要自己能找到。 则在终端输入curl $ curl curl: try 'curl --help' or 'curl --manual' for more information 这样就没错，要是报错，那我就不知道了！ 然后在终端进入存放这个文件的目录（这个不用我教吧），然后终端输入 ruby brew_install.rb 然后等安装homebrew吧！ 作者：kangxx 链接：https://www.jianshu.com/p/68efabd2e32b 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

一、为什么要用分布式ID？ 在说分布式ID的具体实现之前，我们来简单分析一下为什么用分布式ID？分布式ID应该满足哪些特征？ 1、什么是分布式ID？ 拿MySQL数据库举个栗子： 在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。 但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。 2、那么分布式ID需要满足那些条件？ 全局唯一：必须保证ID是全局性唯一的，基本要求 高性能：高可用低延时，ID生成响应要块，否则反倒会成为业务瓶颈 高可用：100%的可用性是骗人的，但是也要无限接近于100%的可用性 好接入：要秉着拿来即用的设计原则，在系统设计和实现上要尽可能的简单 趋势递增：最好趋势递增，这个要求就得看具体业务场景了，一般不严格要求 二、 分布式ID都有哪些生成方式？ 今天主要分析一下以下9种，分布式ID生成器方式以及优缺点： UUID 数据库自增ID 数据库多主模式 号段模式 Redis 雪花算法（SnowFlake） 滴滴出品（TinyID） 百度 （Uidgenerator） 美团（Leaf） 那么它们都是如何实现？以及各自有什么优缺点？我们往下看 图片源自网络，如有侵权联系删除 1、基于UUID 在Java的世界里，想要得到一个具有唯一性的ID，首先被想到可能就是UUID，毕竟它有着全球唯一的特性。那么UUID可以做分布式ID吗？答案是可以的，但是并不推荐！ public static void main(String[] args) { String uuid = UUID.randomUUID().toString().replaceAll("-",""); System.out.println(uuid); } UUID的生成简单到只有一行代码，输出结果 c2b8c2b9e46c47e3b30dca3b0d447718，但UUID却并不适用于实际的业务需求。像用作订单号UUID这样的字符串没有丝毫的意义，看不出和订单相关的有用信息；而对于数据库来说用作业务主键ID，它不仅是太长还是字符串，存储性能差查询也很耗时，所以不推荐用作分布式ID。 优点： 生成足够简单，本地生成无网络消耗，具有唯一性 缺点： 无序的字符串，不具备趋势自增特性 没有具体的业务含义 长度过长16 字节128位，36位长度的字符串，存储以及查询对MySQL的性能消耗较大，MySQL官方明确建议主键要尽量越短越好，作为数据库

- 起源 - TCC概念由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出, 在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司，并且还注册了TCC商标。国内最早可查引进TCC概念，应是阿里程立2008年在 软件开发2.0大会 上分享主题《大规模SOA系统中的分布事务处理》中。 Atomikos公司在商业版本事务管理器ExtremeTransactions中提供了TCC方案的实现，但是由于其是收费的，因此相应的很多的开源实现方案也就涌现出来，如：ByteTCC、Himly、TCC-transaction。但是笔者都不推荐使用，下文会详细说明。 - 组成 - TCC 是一种补偿型事务，该模型要求应用的每个服务提供 try、confirm、cancel 三个接口，它的核心思想是通过对资源的预留(提供中间态，如账户状态、冻结金额等)，尽早释放对资源的加锁，如果事务可以提交，则完成对预留资源的确认，如果事务要回滚，则释放预留的资源。 TCC模型完全交由业务实现，每个子业务都需要实现Try-Confirm-Cancel三个接口，对业务侵入大，资源锁定交由业务方。 1、Try：尝试执行业务，完成所有业务检查(一致性)，预留必要的业务资源(准隔离性)。 2、Confirm：确认执行业务，不再做业务检查。只使用Try阶段预留的业务资源，Confirm操作满足幂等性。 3、Cancel：取消执行业务释放Try阶段预留业务资源。 一个完整的业务活动由一个主业务服务与若干子业务服务组成： 1、主业务服务负责发起并完成整个业务活动 2、业务服务提供TCC型业务操作。 3、业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的Confirm操作，在业务活动取消时调用所有TCC型操作的Cancel操作。 成本： 1、 实现TCC操作的成本 2、业务活动结束时Confirm或Cancel操作的执行成本。在Confirm和Cancel范围内的操作成功性需要框架来保证，只能一直重试保证资源被消耗或者释放。 3、业务活动日志成本 适用范围： 1、强隔离性、严格一致性要求的业务活动 2、适用于执行时间较短的业务 - TCC与2PC对比 - TCC将事务提交划分成两个阶段，Try即为一阶段，Confirm 和 Cancel 是二阶段并行的两个分支，二选一。从阶段划分上非常像2PC，我们是否可以说TCC是一种2PC或者2PC变种呢？其实不可以，原因如下： 1、2PC的操作对象在于资源层，对于开发人员无感知；而TCC的操作在于业务层，具有较

In this article, we will talk about generating Java code from Swagger files, which are essentially API specification files for a Web Service. Below video discusses this with the demo. Open API In our previous article, we talked about SOAP services. The challenge with SOAP services is that they tend to be heavy because of XML data usage, and there is a very tight coupling between the client and server. With time, REST Web Services have become the de-facto standard for Web Services, because of their extensibility. REST APIs are documented using the Open API specifications. Open API is a specification for machine-readable interface files for describing, producing, consuming and visualizing RESTful Web Services. These were earlier called swagger specifications when they were developed by [SmartBear Software]. Because of a standard specification, APIs created with this have a common structure and it allows to build tooling around the APIs to cut down on the amount of boilerplate code. Let’s see an example Swagger API. Petstore Swagger API Petstore API is the example Swagger API hosted at swagger.io. The API allows you to manage pets in a store. The API can be viewed in the Swagger UI, which gives a very detailed view of the API, the available operations, the request parameters, headers, authorization, response, all of it. It becomes a handy document for reference as well. Swagger-Codegen Since, Swagger API has well-defined structure, it can be used to generate Java classes for Rest API service and get the API integration going in no time. Swagger Codegen is designed for exact same purpose. Its comes as a standalone binary as well as Maven plugin, to generate the code, and that is what we will use for the Petstore API demo. Project The initial project used in this article is available here. Here are the contents of the Project -> tree . . ├── pom.xml └── src ├── main │   ├── java │   └── resources └── test ├── java

说明 接着上次手撕面试题ThreadLocal！！！面试官一听，哎呦不错哦！本文将继续上文的话题，来聊聊FastThreadLocal，目前关于FastThreadLocal的很多文章都有点老有点过时了（本文将澄清几个误区），很多文章关于FastThreadLocal介绍的也不全，希望本篇文章可以带你彻底理解FastThreadLocal！！！ FastThreadLocal是Netty提供的，在池化内存分配等都有涉及到！ 关于FastThreadLocal，零度准备从这几个方面进行讲解： FastThreadLocal的使用。 FastThreadLocal并不是什么情况都快，你要用对才会快。 FastThreadLocal利用字节填充来解决伪共享问题。 FastThreadLocal比ThreadLocal快，并不是空间换时间。 FastThreadLocal不在使用ObjectCleaner处理泄漏，必要的时候建议重写onRemoval方法。 FastThreadLocal为什么快？ FastThreadLocal的使用 FastThreadLocal用法上兼容ThreadLocal FastThreadLocal使用示例代码： public class FastThreadLocalTest { private static FastThreadLocal<Integer> fastThreadLocal = new FastThreadLocal<>(); public static void main(String[] args) { //if (thread instanceof FastThreadLocalThread) 使用FastThreadLocalThread更优，普通线程也可以 new FastThreadLocalThread(() -> { for (int i = 0; i < 100; i++) { fastThreadLocal.set(i); System.out.println(Thread.currentThread().getName() + "====" + fastThreadLocal.get()); try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); } } }, "fastThreadLocal1").start(); new FastThreadLocalThread(() -> { for (int i = 0; i < 100; i++) { System.out.println(Thread.currentThread().getName() + "====" + fastThreadLocal.get()); try { Thread.sleep(200); } catch (InterruptedException e) { e.printStackTrace(); } } }, "fastThreadLocal2").start(); } } 代码截图： 代码运行结果： 我们在回顾下之前的ThreadLocal的 最佳实践做法： try { // 其它业务逻