download：Go 开发者的涨薪通道自主开发 PaaS 平台外围性能无密分享
开发
首先说一下后端开发。罕用的语言有 Java，Golang，Python。Java 程序员是目前市面上最多的，很多公司都会抉择。Java 语言开发的整个后端我的项目都有很好的我的项目标准，适宜简单的业务逻辑。自己从事 Golang 语言，适宜开发微服务，特点是开发快，效率高。大多数公司 (Go，字节的次要语言，哔哩哔哩的 Go，腾讯的 Go 等。) 都开始抉择 Golang 进行开发，因为与 Java 和 Python 相比，这种语言最大的特点就是节俭内存，反对高并发，简洁高效，简略易学。
Golang 语言的后端框架有很多，比方 Gin(举荐)、Beego、Iris 等。关系数据库的操作包含 gorm。以上是 Golang 后端开发曾经把握的根本能力。
微服务框架包含: 归零奎托斯
Golang 语言有一些独特的性能，比方 coroutine goroutine，它比 threads 更轻量级、更高效。例如，通道是通过共享内存反对过程间通信的一种形式。当多个 goroutine 生产通道中的数据时，通道中反对锁机制，每条音讯只会调配给一个 go routine 生产。在 Golang 外部，有一套残缺的 Goroutine 调度机制 GMP，其中 g 指 goroutine，m 指机器，p 指流程。GMP 的原理大抵是通过全局缓存和每个线程的缓存来保留须要运行的 go routine，通过过程的协调将 go routine 散发到无限的机器上运行。
Golang 是一种反对 GC 的语言，外部应用三色标记垃圾收集算法。原理大抵是通过可达性算法对那些被援用的对象进行标记，对残余的须要开释的未标记对象进行回收。在旧版本中，STW 影响很大。所谓的 STW 是在 GC 中，因为多线程拜访内存会导致不平安的问题。为了保障内存 GC 的准确性，在标记对象时，它会阻止程序代码持续运行通过一道屏障，而后持续运行程序，直到所有的对象都被解决完。这个短暂的工夫被称为 STW(进行世界)。因为 STW，会导致程序无奈提供服务的问题。在 Java 中，这种景象也存在。然而随着 Golang 版本的更新，GC 算法一直优化，STW 工夫越来越短。
须要留神的是，在定义 map 时，尽量不要将指针存储在值中，因为这样会导致 GC 工夫过长。
另一个知识点是 Golang 的地图是一个无序的地图。如果须要从地图上遍历数据，须要用 slice 保留，并依照肯定的程序排序，这样能力保障每次查问的数据都是同一个程序。而且地图是无锁的，不平安。应用 map 进行内存缓存时，须要思考多线程拜访缓存带来的平安问题。常见的办法有两种，一种是增加读写锁 RWLock，另一种是应用 sync。Map 在多写少读的场景下倡议应用 RWLock，因为 sync。Map 外部用空间换工夫的办法，外部有两张地图，一张反对浏览，一张反对写作。写的太频繁，会导致 map 的不断更新，带来频繁的 GC 操作，带来比拟大的性能开销。
Golang 的 Goroutine 是无国籍的。如果须要 main 函数期待 Goroutine 完结或终止 Goroutine，通常有三种办法。第一种是在 sync 中应用 WaitGroup，它包含 Add、Done 和 wait 办法。能够比作 Java 中的 CountDownLatch。第二种办法是应用 Context 包中的 Done 办法将主函数的上下文带入 Goroutine，同时应用主函数中的 select 来监听 Goroutine 接管到的上下文收回的 Done 信号。第三种办法是定义一个通道，并将其发送到 Goroutine 中。在 Goroutine 中执行后，main 函数期待读取发送给通道的终止信息。
Golang 没有继承的概念，只有组合的概念。每个构造的定义能够看作一个类，构造和构造能够组合嵌套。在软件设计原理中，类的组合比类的继承更能达到解耦的成果。Golang 没有显著的接口实现逻辑。当构造实现接口申明的所有办法时，默认状况下，该构造实现接口。在函数调用的参数中，咱们通常是从调用方传入实现这个接口的 struct，在要接管的函数体的接管参数中定义这个接口，从而达到被调用函数的重用成果。这也是多态思维在面向对象个性中的体现。
在 Golang，谬误的解决是最苦楚的。基本上，十个函数调用中有九个会返回一个谬误，每个谬误都须要解决或抛出。通常，在业务逻辑中，咱们会自定义谬误并申明谬误的类型。在 Golang 官网的 Errors 包中，error 只是一个 struct，提供 New、Wrap、error 等办法，提供创立谬误、抛出谬误、输入错误信息等性能。所以须要留神的是，咱们不能用 string 的等价来比拟 errors 是否雷同，因为 error 是 struct，是 instance 对象。尽管两个谬误的值信息是一样的，然而对象只是内存中的一个存储地址值，两者并不相同。通常，在函数的第一行，咱们应用 defer 函数来对立处理函数体中的所有谬误。Defer 是提早解决标记，函数在返回前截取并解决 defer 匿名函数中的代码。(能够用 pkg/errors 包解决)
Golang 的我的项目构造在 github 中有一个家喻户晓的例子，能够参考或者模拟。须要留神的是，当内部我的项目须要调用我的项目的代码时，只能调用 internel 包之外的函数或对象办法。对于 internel 包中的代码，它不可用于内部调用我的项目。这也是一种代码爱护机制。
关系型数据库
后端我的项目离不开数据的增删查。通常人们接触最多的是 MySQL，所以举荐看 MySQL 45。
MySQL 罕用的版本有 5.7 和 8.0。通常，为了向前兼容，大多数公司应用 MySQL 版本。在这个版本中，MySQL 默认反对 InnoDB 存储引擎，这个引擎的特点就是反对事务，也就是咱们常说的 ACID。
一般来说，如果须要对多个表进行增加、批改、删除等操作，为了避免多阶段操作的成败不统一，须要应用事务个性。如果操作齐全失败，事务将回滚，所有操作将被勾销。
事务隔离有四个级别，即未提交读、提交读、可反复读和序列化。默认状况下，MySQL 中 InnoDB 反对的事务隔离级别是可反复的。
应该留神，对于每个隔离级别的事务，存储引擎将提供相应的锁定机制。大家操作数据的时候要留神死锁。在数据读取和操作中，反对读写锁。读锁是共享锁，能够同时领有多个读锁。写锁也叫排他锁，同一时间只容许一个写锁对数据进行操作。不同的存储引擎有不同的锁级别，包含表锁、行锁和间隙锁。请留神，在执行删除或更新操作时，最好采纳 where 条件来避免整个表被删除或更新，或者避免因为接触表锁而导致的死锁。
索引搜寻和全表扫描的数据查问效率差距很大。实质起因是在 InnoDB engine 中，会为索引表字段构建一个 B + 树，以进步查问效率。在编写查问语句的过程中，尽量注明须要查问的字段，这样如果曾经为查问的字段创立了联结索引，InnoDB search 就不须要返回表了。+ B 树的叶节点通常存储表的主键。通过查问条件在索引 B + 树中找到对应的主键，而后在以主键为查问条件建设的 B + 树中找到整行数据。咱们称之为 table return，在 B + 树中会被查问两次。
联结索引反对的查询方法是最左匹配准则。如果查问语句中的 where 条件没有依照 union 索引的最左匹配准则进行查问，InnoDB 会扫描整个表。索引优化应用 Explain 语句。
在表格设计中，一个表格中不能有太多的字段，个别不超过 20 个字段。每个字段的字段类型要依据理论状况尽量减少。比方 uuid 默认为 32 位，那么定义 varchar(32)就够了，定义 varchar(255)会节约空间。
在分页查问中，limit 反对两个字段，page 和 pageSize。页面越大，查问效率越低。所以，尽量设计一个主动递增的整数字段。当页面过大时，能够通过增加过滤主动递增整数字段的 where 条件来进步查问效率。
默认状况下，MySQL 是独立的存储。对于多读少写的业务场景，能够从主部署到从，反对读写拆散，加重写服务器压力。
MySQL 最多只能反对几 K 并发。对于大量并发查问数据的场景，倡议在上游减少 Redis、Memcached 等缓存服务。
MySQL 在操作数据时提供 binlog 日志，通常应用 cancal 等组件服务将数据导出到音讯队列中进行剖析、特定搜寻、用户举荐等场景。如果 MySQL 服务器数据失落，还能够应用 binlog 日志进行数据恢复。然而，因为数据操作会在零碎内存中存储一段时间，并定期刷新到硬盘，所以 binlog log 并不能完全恢复所有数据。
应用心得
当用户数量剧增，拜访频繁时，在 MySQL 上游减少一个缓存服务来同步一些热点数据，能够加重数据库拜访的压力。常见的缓存服务是 Redis。
Redis 是用 C 语言编写的基于内存的分布式缓存组件。其特点是反对大量的读写场景和高效的数据查问。
尽管 redis 是分布式缓存，但为了避免服务宕机，通常采纳长久化机制将数据保留到硬盘。redis 反对的持久性机制包含 AOF 和 RDB。AOF 记录每个写入、更改和删除操作的日志，在服务敞开后，它通过操作日志从新执行命令来复原数据。RDB 记录数据快照，在服务进行后，它通过数据快照复原该时间段之前的所有数据。总的来说，两者都有各自的毛病。AOF 的毛病是数据恢复比较慢，RDB 的毛病是定期进行数据快照，所以停机到最初一次数据快照这段时间的数据操作会失落。因而，咱们将同时应用两者。倡议 RDB 距离不要设置太短，因为在 RDB 快照期间执行外部 bgsave 命令会导致 redis 短时间内无奈提供服务。
尽管 redis 能够无效升高数据库拜访的压力，但它并不是银弹。如果数据最终是基于数据库的，那么在读写数据时就要思考缓存和数据库的不一致性。
redis 与 mysql 数据一致性的解决方案
读: 如果 redis 的一个数据过期了，间接从 Mysql 查问数据。
操作: 先更新 Mysql，再更新 Redis 如果更新 redis 失败，能够思考再试一次。
对于以上操作，如果依然存在不统一的状况，能够思考减少一个自底向上的计划来监控 mysql binlog 日志，而后将 binlog 日志发送到 kafka 队列进行生产。
redis 引入后，除了数据不统一，还可能呈现缓存雪崩、缓存穿透、缓存击穿等问题。减少缓存时，尽量设置不同的缓存生效工夫，避免大量缓存数据同时生效，数据拜访 db 造成 db 拜访压力过大的问题；缓存穿透能够思考 Bloom filter，缓存击穿能够思考分布式锁解决方案。
redis 之所以读取效率快，是因为内存中存在大量的数据。如果须要大量的缓存数据进行存储，那么单机的内存容量是无限的，所以 redis 须要部署在集群中。redis 的集群部署和存储形式是在每个 redis 服务器上均匀分布 10000 多个拆分槽，redis 的 key 通过统一 hash 将数据存储在一个槽对应的 redis 服务器上。redis 的扩大和膨胀会引起大量的数据迁徙。此时尽量进行对外服务，否则缓存数据可能会生效。
Redis 通过哨兵机制发现了服务高低稳定的问题。通常的部署模式是一主二从三哨。
redis 的利用场景有很多，比方用 zset 实现排名，用 list 实现轻量级音讯队列，用 hash 集实现微博点赞等等。
在存储 redis 时，须要留神的是，key 值不能是中文，value 值不能太大。在设计密钥时，应依据业务对立密钥的设计规范。
尽管 redis 有 16 db 库，但它们只是逻辑上隔离的。缓存的数据都存储在一个中央，不同 db 库的读写是竞争的。
卡夫卡
接下来说音讯队列，这里就只说卡夫卡吧。
音讯队列的利用场景就不用说了。只是依据理论场景应用上下游解耦，流量削峰，异步解决等等。
上面说一些音讯队列会遇到的常见问题。如音讯失落、反复发送音讯、音讯重试机制、音讯程序、反复耗费音讯等。
在卡夫卡那里，音讯的失落是极低的，因为卡夫卡是一种机制，保障了至多一次传输。只有是 HW 内的 offset，Kafka 默认曾经长久化到硬盘，所以如果耗费 HW 内的 offset 音讯，不会有音讯失落。
Kafka 为音讯发送提供了 ACK 机制。这种 ACK 机制有三个值可供选择。
当 ACK= 0 时，即音讯发送到 leader 时，确认音讯发送胜利。此时，不晓得其余复制品是否保留了该音讯。在这种状况下，很有可能音讯发送了，然而失落了。如果此时首节点进行运行，其余正本将为首节点运行。在某个正本为领导者运行之后，Kafka 引入了领导者 epoach 机制来截断日志。此时，如果正本直到领导者收到此音讯后才同步，则音讯将会失落。
当 ACK= 1 时，音讯被发送到该分区下的 ISR 集中的所有正本。当 ISR 汇合中有多个正本时，即便领袖所在的节点呈现故障，也不会有音讯失落。因为分区下的 leader 默认从 ISR 汇合中产生，并且 ISR 汇合中的所有正本都曾经存储了该音讯，因而失落的可能性简直为零。
当 ACK=- 1 时，音讯被发送到分区下的所有正本。无论领导所在的节点是否宕机，或者这个 ISR 下是否只有一个正本，只有这个 Paris 下有多个正本，音讯就不会失落。
日常状况下，咱们默认 ACK=1，因为 ACK= 0 音讯很可能会失落，而 ACK=- 1 音讯发送工夫太长，发送效率太低。
对于音讯反复发送的问题，我倡议从生产端解决。对于制作者来说，如果发送了音讯然而没有收到 ACK，然而音讯理论发送胜利然而判断音讯失败，对于反复发送的场景，卡夫卡无能为力。然而，能够关上事务机制，以确保只发送一次。但一旦开启交易，卡夫卡的发送生产能力会大打折扣，不倡议开启交易。
在 Kafka 中，生产者收回的每一条音讯都会存在于相应主题下的分区中的一个偏移量上。音讯发送必须指定主题，有或没有分区。当未指定分区时，主题下的音讯将通过负载平衡散布在每个分区下。因为只有在同一个分区下的音讯才是有序的，所以如果在向一个有多个分区的主题发送音讯时没有指定分区，那么音讯就会乱序。
卡夫卡逻辑上按主题隔离音讯，物理上按主题下的分区隔离音讯，并在主题下划分多个分区，目标是为了进步消费者的生产能力。一个分区只能由一个使用者应用，然而一个使用者能够应用多个分区。每个消费者终端将被调配到一个消费者组。如果该消费群中只有一个生产终端，则该消费群订阅的主题下的所有分区都将被该生产终端生产。如果消费者组中的消费者终端数量小于或等于主题下的分区数量，则消费者组中的消费者终端将被平均分配到肯定数量的分区中，能够是一个分区，也能够是多个分区。相同，如果消费群组中的生产终端数量大于 topic 下的分区数量，那么消费群中就会呈现无奈分区，无奈生产数据的消费者。
在理论利用场景中，消费者终端的数量通常等于消费者组中的分区数量。确保每个使用者在分区下至多应用一条偏移音讯。
Kafka 集群的每个服务称为 broker，zookeeper 会在多个 broker 中选出一个控制器来解决外部申请和内部操作。然而真正的数据读写操作都产生在分区上，属于一个主题。为了避免数据失落，通常有多个分区，每个分区称为正本。每个分区从多个正本中抉择一个分区领导者，负责数据的读写。其余正本负责领导者交互和数据同步。同一分区下的多个正本将均匀散布在不同的代理中。所以在设计上能够发现，其实卡夫卡的音讯解决是负载平衡的，基本上每个经纪人都会参加。默认状况下，分区的领导者是从 ISR 汇合中选出的。ISR 的全称是“同步正本”, 意思是与领导传播的信息统一的正本。如果在肯定工夫内，或者在肯定数量的偏移量内，复制品与领导者的偏移量不统一，那么它就不能存在于 ISR 汇合中。即便之前存在于 ISR 汇合中，也会被踢出去。期待一段时间后，音讯在退出 ISR 集之前会进行工夫同步。所以在肯定水平上，首领是从 ISR 汇合中选取的，以保障首领改选时音讯会同步统一，不会失落。
因为卡夫卡引入了生产群体机制，能够大大提高消费者的生产能力。然而，因为生产群体的再均衡机制，消费者的生产将临时无奈取得。问题是这样的，因为在消费群中有一个叫做 coordinate 的均衡器，负责将分区平均分配到消费群的各个生产端。如果使用者组中的使用者端减少或缩小，那么分区须要重新分配。此时，该消费群下的所有生产端都会进行生产，期待坐标给他重新分配一个新的分区。消费者和分区越多，这个等待时间就越长。所以不倡议在 topic 下设置太多分区设置，个别在 20 以内。