皮皮网

1.Linux C/C++开发（后端/音视频/游戏/嵌入式/高性能网络/存储/基础架构/安全）
2.Linux内核网络分层模型——skb核心操作
3.一文帮你一劳永逸解决Lua面向对象
4.xfs文件系统：layout与架构、鹅厂鹅厂源码分析
5.鹅厂微创新Golang缓存组件TCache介绍
6.golang本地缓存(bigcache/freecache/fastcache等)选型对比及原理总结

Linux C/C++开发（后端/音视频/游戏/嵌入式/高性能网络/存储/基础架构/安全）

       C++后台开发，也称为C++/Linux服务器开发，什平在BAT公司中拥有众多职位，鹅厂鹅厂其中鹅厂对C++后台开发岗位的源码需求尤为迫切。尽管该岗位对技术要求较高，什平as打地鼠源码但追求大厂工作的鹅厂鹅厂朋友仍可积极争取。

       对于具有C/C++语言基础的源码朋友来说，在面试后台岗位时，什平常常会疑问：面试大厂时，鹅厂鹅厂技术水平需达到何种程度才能入职？以下是源码针对校招和社招的不同要求。

       对于校招，什平技术层面的鹅厂鹅厂要求相对较低。掌握C with STL以及常见的源码数据结构与算法，且能完成leetcode中等难度以下题目的什平笔试者，已有分。如果对STL、auto、lambda等用法熟练，还能加分。对于实习生来说，良好的表现即可被录用，之后会再进行网络编程和Linux方面的培训。

       因此，校招更看重的是基础和学习能力。实习期间，会根据技术学习进度决定是否发放offer。当然，如果提前掌握Linux环境编程、网络编程等技术，更能加分，因为各个赛道都有内卷现象。

       对于社招，C++后台开发岗位的核心技术点有三个：代码能力、架构能力、安全能力及工程素养。掌握这三方面的技术，面试通过的概率较高。至于在大厂的职级体系中确定自己的岗位，会有更加细化的标准。

       不熟悉的朋友，可以先领取一份Linux c/c++开发新手学习资料包（入坑不亏）：LinuxC++后台开发文档视频+代码资料学习路线免费领取

       Linux C/C++开发1、精进基石专栏

       （一）数据结构与算法

       （二）设计模式

       （三）c++新特性

       （四）Linux工程管理

       2、高性能网络设计专栏

       （一）网络编程异步网络库zvnet

       （二）网络原理

       （三）自研框架:基于dpdk的用户态协议栈的实现(已开源)

       3、基础组件设计专栏

       （一）池式组件

       （二）高性能组件

       （三）开源组件

       4、中间件开发专栏

       （一）Redis

       （二）MySQL

       （三）Kafka

       （四）Nginx

       5、开源框架专栏

       （一）游戏服务器开发skynet (录播答疑)

       （二）分布式API网关

       （三）SPDK助力MySQL数据落盘，swift语音识别源码 让性能腾飞(基础设施)

       （四）高性能计算CUDA (录播答疑)

       （五）并行计算与异步网络引擎workflow

       （六）物联网通信协议mqtt的实现框架mosquitto

       6、云原生专栏

       （一）Docker

       （二）Kubernetes

       7、性能分析专栏

       （一）性能与测试工具

       （二）观测技术bpf与ebpf

       （三）内核源码机制

       8、分布式架构

       （一）分布式数据库

       （二）分布式文件系统(录播答疑)

       （三）分布式协同

       9、上线项目实战

       （一）dkvstore实现(上线项目)

       （二）图床共享云存储(上线项目)

       （三）容器化docker部署

       （四）零声教学AI助手一代(上线项目)

       （五）魔兽世界后端TrinityCore (上线项目)

       、适宜的工程师人群（共分为8大群体）

       、配套书籍资料

       以上是系统学习课程大纲，需要系统学习或者领取视频资料点下方腾讯文档领取

       如果想在大厂快速提升C/C++开发方向的能力，这份学习体系是大家绕不过的具有参考意义的提升路线。通过学习路线，可以对Linuxc/c++开发方向的技术栈有清晰的认识。

Linux内核网络分层模型——skb核心操作

       Linux内核的网络操作是基于分层设计的，可以形象地比喻为一个数据包的“栈”操作。数据包的形成是通过逐层封装，即所谓的push操作，而解封装则是逐层弹出，即pop操作。核心数据结构sk_buff在这一过程中起到了关键作用。

       sk_buff操作涉及的步骤包括：首先，通过alloc_skb分配sk_buff结构和数据包缓冲区，初始化大小；接着，进行初始定位（skb_reserve），确定应用层数据的起始位置；然后，使用skb_push将应用层数据复制到skb，并设置传输层、IP层和以太帧头部。这个过程类似于“堆栈”上逐层添加协议头，直至形成完整的以太帧。

       在实际操作中，需要注意接口编程，比如正确设置协议头的位置，避免使用绝对地址，而应依赖于NET_SKBUFF_DATA_USES_OFFSET宏。此外，sk_buff的设计还考虑了不同系统架构下的指针长度问题，通过sk_buff_data_t类型统一处理。

       然而，本文并未详尽探讨sk_buff的所有细节，只是概述了其基本操作和一些关键接口，如alloc_skb、skb_reserve、skb_push等。尽管sk_buff的深度和复杂性远超本文所展示，但掌握这些基础操作对于理解网络数据包的传输至关重要。

       总结来说，sk_buff的APS 排产源码核心操作是网络分层模型中的重要一环，通过理解和实践这些操作，可以更好地掌握数据包在网络中的封装和传输过程。

       相关链接：

       视频教程高薪岗位DPDK高性能虚拟专家学习路线

       备战秋招：C/C++程序员音视频流媒体开发

       鹅厂T8认证：年LinuxC/C++后台开发学习路线

       互联网大厂秋招：嵌入式入门到精通

       Linux内核技术交流群：

       最新Linux内核源码资料文档+视频资料

       学习内容：Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈

一文帮你一劳永逸解决Lua面向对象

       解决Lua面向对象难题的实用指南

       在Lua中，元表的使用常常令人困惑，尤其是在实现面向对象时。通过对比其他语言的面向对象特性，我们可以理解其复杂性（来自韦亦笑的回答）。因此，理解和掌握如何有效地运用元表，特别是__index元方法，是至关重要的。

       Lua的元表机制允许我们操作运算符，实现面向对象。通常，通过设置__index，我们能模拟类和继承。例如，通过将类对象作为衍生对象的元表，我们可以实现简单的继承。然而，这种手动方式存在诸多问题，如难以扩展和维护。

       为简化面向对象编程，一个辅助模块应运而生。这个模块提供接口，允许开发者避免模式化代码，实现全量面向对象。设计上，模块包括工具函数，如用于继承和多继承的函数，以及处理数据继承和初始化的机制。它还支持自定义元方法，确保与Lua元表机制的兼容性，并提供了`IsClass`函数来判断对象类型。

       实现上，实例化运算符的`is`和`as`功能并不需要，因为Lua的动态类型和鸭子类型特性。尽管过程复杂，但通过深度优先遍历实现的面向对象机制，最终实现了所需的功能，如构造函数和纯虚函数的实现。

       使用这个模块，我们可以更直观地实现最初的面向对象示例，而无需担心繁琐的元表操作。尽管实现过程曲折，但结果是资金互助系统源码一个强大且实用的工具，极大地简化了Lua的面向对象编程。

       为了获取更多实例和源代码，不妨关注鹅厂架构师公众号，探索更多技术分享。

xfs文件系统：layout与架构、源码分析

       本文由腾讯工程师aurelian撰写，深入解析Linux内核中xfs文件系统的layout与架构，结合源码剖析其工作原理。首先，xfs的layout包括超级块、AGF管理（空闲空间追踪）、AGI管理（inode管理）、AGFL（空闲链表）以及B+树结构等组成部分，每个部分都有其特定功能，如超级块用于存储关键信息，B+树用于快速查找空间。

       在文件操作方面，xfs支持iops、fops和aops三个操作集，分别负责inode元数据、内存级读写和磁盘级读写。创建文件时，会检查quota并预留空间，通过一系列函数如xfs_trans_reserve_quota和xfs_dir_ialloc进行操作。分配inode时，会依据agi信息和ag的空闲情况动态分配，并通过xfs_iget确保inode在核心内存中可用。

       磁盘级inode分配涉及agi信息的获取和B+树的查找，xfs_ialloc_ag_alloc会根据空闲inode情况完成连续或非连续的分配。写操作涉及内存和磁盘级别，buffer io通过page cache管理，直接io和DAX write则有特定的处理方式。xfs的映射关系和data区域树管理对于高效读写至关重要。

       工具方面，mkfs.xfs用于格式化，xfs_fsr、xfs_bmap、xfs_info等用于维护和监控文件系统，xfs_admin和xfs_copy用于系统参数调整和数据复制，xfs_db则是用于调试的工具。希望本文能帮助读者理解xfs的复杂性，如需了解更多详情，可关注鹅厂架构师公众号。

鹅厂微创新Golang缓存组件TCache介绍

       一个 Golang 自研小组件，TCache 介绍

       作者：frank、maxy、手机水印电脑源码lark 等。

       TCache 是一个 Golang 团队自研的缓存组件，旨在优化视频会员场景下高并发请求的压力，减少底层存储压力，提升系统可用性。设计时，我们考虑了开源组件如布隆过滤器、位图、localcache 的特点和优劣，以业务需求为出发点，集成这些组件形成整体解决方案。

       TCache 设计目标

       主要目标是为视频会员服务提供高效缓存，应对大量 APP 请求，减轻存储层压力，并增强系统稳定性。经过调研，我们发现现有开源组件适合不同场景，因此决定整合这些组件，通过配置化设计，让业务根据自身需求选择合适的缓存策略。

       整体架构

       TCache 分为四层架构：业务场景层、中间件层、组件层与算法层。业务场景层直接与应用交互，中间件层集成了多种缓存算法，组件层基于开源组件实现，算法层则深入研究缓存技术原理。

       组件结构

       TCache 集成了多种缓存组件，包括 KV 型结构 Cache、BitMap、BloomFilter 与大型计数器 Hyperloglog。此外，我们计划集成更多组件以覆盖更多业务场景。

       Cache 组件设计

       提供了统一的 cache 接口，支持用户自定义底层缓存实现，包括默认实现与本地缓存组件 localcache 的接口定义。

       BitMap 组件设计

       BitMap 组件集成经典 BitMap 与 Roaring 位图算法，提供单一操作 API，便于业务集成使用。组件结构清晰，代码接口明确。

       开发过程

       TCache 的开发过程始于团队转型 Golang 时的技术积累与开源组件分析，通过源码阅读、论文研读，深入了解组件技术，最终形成组件化设计。团队持续研究缓存替换算法、位图算法，通过实验对比分析，提炼出业务适用的缓存策略。

       功能分析

       本地缓存强调数据一致性与吞吐量，支持多线程访问与内存限制，适用于缓存热点数据。常见组件如 freecache、fastcache、bigcache 等，提供线程安全、高命中率与高效管理的特性。

       源码分析

       深入研究开源组件，如 BigCache、BloomFilter、RoaringBitmap，通过建模与代码分析，了解组件实现原理与优化策略。

       算法研究

       研究缓存替换算法，包括 Belady 最优策略、随机策略、先进先出、最近不使用、最不经常使用、重引用间隔预测等。通过实验对比分析，提炼出适用于不同场景的缓存策略。

       实验研究

       通过功能与性能对比研究，推荐不同缓存组件在特定场景下的应用，如 freecache、bigcache、fastcache、localcache 等，以及针对数据持久化与热启动的组件。

       组件化

       整合多种组件形成 TCache，通过组件化设计，让业务灵活选择缓存策略，提高系统性能与稳定性。

       总结

       TCache 的开发是一个无心插柳的成果，整合了团队的技术积累与业务需求。通过研究、实验与优化，我们找到了适合视频会员服务的缓存解决方案。未来，结合 AIGC 等新技术，开发出更多原创组件，有可能推动开发行业的变革。

golang本地缓存(bigcache/freecache/fastcache等)选型对比及原理总结

       以下内容来自腾讯后台研发工程师jayden

       导语：提到本地缓存大家都不陌生，只要是个有点经验的后台开发人员，都知道缓存的作用和弊端。本篇文章我们就来简单聊聊在golang做业务开发的过程中，本地缓存的一些可选的开源方案，分析它们的特点，以及内部的实现原理。

       1.本地缓存需求分析

       首先来梳理一下业务开发过程中经常面临的本地缓存的一些需求。我们一般做缓存就是为了能提高系统的读写性能，缓存的命中率越高，也就意味着缓存的效果越好。其次本地缓存一般都受限于本地内存的大小，所有全量的数据一般存不下。那基于这样的场景一方面是想缓存的数据越多，则命中率理论上也会随着缓存数据的增多而提高；另外一方面是想，既然所有的数据存不下那就想办法利用有限的内存存储有限的数据。这些有限的数据需要是经常访问的，同时有一定时效性(不会频繁改变)的。基于这两个点展开，我们一般对本地缓存会要求其满足支持过期时间、支持淘汰策略。最后再使用自动管理内存的语言例如golang等开发时，还需要考虑在加入本地缓存后引发的GC问题。

       分析完我们日常本地缓存的诉求，再结合我们日常开发用到的golang语言，我们可以提炼得到golang本地缓存组件必须具备以下几个能力：

       分析清楚了我们的需求，也明确了我们需要的能力。那自然优先考虑golang内置的标准库中是否存在这样的组件可以直接使用呢？很遗憾，没有。golang中内置的可以直接用来做本地缓存的无非就是map和sync.Map。而这两者中，map是非并发安全的数据结构，在使用时需要加锁；而sync.Map虽然是线程安全的。但是需要在并发读写时加锁。此外二者均无法支持数据的过期和淘汰，同时在存储大量数据时，又会产生比较频繁的GC问题，更严重的情况下导致线上服务无法稳定运行。

       既然标准库中没有我们满足上述需求的本地缓存组件，那我们就想只有两种解决方案了

       那首先面临的第一个问题就是方案的调研和选型，没有合适的方案时自己再来动手构建。下面我们就来给大家介绍下golang中哪些可以直接来使用的本地缓存组件吧。

       2.golang本地缓存组件概览

       golang中本地缓存方案可选的有如下一些：

       下面通过笔者一段时间的调研和研究，将golang可选的开源本地缓存组件汇总为下表，方便大家在方案选型时作参考。

       在上述方案中，freecache、bigcache、fastcache、ristretto、groupcache这几个大家根据实际的业务场景首选，offheap有定制需求时可考虑。

       通过上表的总结，个人想再此再谈几点关于本地缓存组件的理解：

       （1）上述本地缓存组件中，实现零GC的方案主要就两种：

       a.无GC：分配堆外内存(Mmap)

       b.避免GC：map非指针优化(map[uint]uint)或者采用slice实现一套无指针的map

       c.避免GC：数据存入[]byte slice(可考虑底层采用环形队列封装循环使用空间)

       （2）实现高性能的关键在于：

       a.数据分片(降低锁的粒度)

       3. 主流缓存组件实现原理剖析

       在本节中我们会重点分析下freecache、bigcache、fastcache、offheap这几个组件内部的实现原理。

       3.1 freecache实现原理

       首先分析下freecache的内部实现原理。在freecache中它通过segment来进行对数据分片，freecache内部包含个segment，每个segment维护一把互斥锁，每一条kv数据进来后首先会根据k进行计算其hash值，然后根据hash值决定当前的这条数据落入到哪个segment中。

       对于每个segment而言，它由索引、数据两部分构成。

       索引：其中索引最简单的方式采用map来维护，例如map[uint]uint这种。而freecache并没有采用这种做法，而是通过采用slice来底层实现一套无指针的map，以此避免GC扫描。

       数据：数据采用环形缓冲区来循环使用，底层采用[]byte进行封装实现。数据写入环形缓冲区后，记录写入的位置index作为索引，读取时首先读取数据header信息，然后再读取kv数据。

       在freecache中数据的传递过程是：freecache->segment->(slot,ringbuffer) 下图是freecache的内部实现框架图。

       总结： freecache通过利用数据分片减小锁的粒度，然后再存储时索引并没有采用内置的map来维护而是采用自建map减少指针来避免GC，同时数据存储时采用预先分配内存然后后边循环使用。通过上述两种方法保证了在堆上分配内存同时减少GC对系统性能的影响。

       3.2 bigcache实现原理

       bigcache和freecache类似，也是一个零GC、高性能的cache组件，但是它的实现和freecache还是有些差异，这儿有篇 英文博客介绍bigcache设计原理的，内容稍长感兴趣的可以阅读下，下面我们介绍一下bigcache的实现原理。

       bigcache同样是采用分片的方式构成，一个bigcache对象包含2^n 个cacheShard对象，默认是个。每个cacheShard对象维护着一把sync.RWLock锁(读写锁)。所有的数据会分散到不同的cacheShard中。

       每个cacheShard同样由索引和数据构成。索引采用map[uint]uint来存储，数据采用entry([]byte)环形队列存储。索引中存储的是该条数据在entryBuffer写入的位置pos。每条kv数据按照TLV的格式写入队列。

       不过值得注意的是，和bigcache和freecache不同的一点在于它的环形队列可以自动扩容。同时bigcache中数据的过期是通过全局的时间窗口维护的，每个单独的kv无法设置不同的过期时间。

       下面是bigcache的内容实现原理框架图。

       总结：bigcache思路和freecache大体相同，只不过在索引存储时更为巧妙，直接采用内置的map结构加上基础数据类型来实现。同时底层存储数据的队列也可以根据空间大小来决定是否扩容。唯一的缺陷是无法针对每个key进行设置不同的过期时间。这个个人认为如果想用bigcache同时想要这个特性，可以进行二次开发一下。

       通过 性能测试数据来看，bigcache性能要比freecache稍微好一点。大家可以思考下他们性能的差异可能会在哪里呢？

       3.3 fastcache实现原理

       本节介绍下fastcache的实现原理，根据fastcache官方文档介绍，它的灵感来自于bigcache。所以整体的思路和bigcache很类似，数据通过bucket进行分片。fastcache由个bucket构成。每个bucket维护一把读写锁。在bucket内部数据同理是索引、数据两部分构成。索引用map[uint]uint存储。数据采用chunks二维的切片(二维数组)存储。不过值得注意的是fastcache有一个很大的特性是，它的内存分配是在堆外分配的，而不是在堆上分配的。堆外分配的内存。这样做也就避免了golang GC的影响。下图是fastcache内部实现框架图。

       总结： fastcache一方面充分利用了分片来降低锁的粒度，另一方面在索引存储时采用了对map的优化，同时在分配内存时，直接从堆外申请内存，自己实现了分配和释放内存的逻辑。通过上述手段使得GC的影响降到了最低。fastcache唯一的缺陷是官方提供的版本没有提供针对kv数据的过期时间这个特性。所以如果需要这个特性的话，需要自己动手二次开发。整体从性能上来看是比bigcache和freecache都更优。

       3.4 offheap实现原理

       本节介绍下offheap的相关内容，offheap其实功能就比较简单了，就是一个基于堆外内存构建的哈希表。它通过直接调用系统调用函数来分配内存。然后在内部通过数组来实现哈希表。实现过程中当发生哈希冲突时，它是采用探测法来解决。由于是在堆外分配的内存上构建的哈希表。导致它的GC开销非常的小。下图是offheap的内部实现框架图。

       总结：offheap内部由于是采用探测法解决哈希冲突的，所以当哈希冲突严重时数据删除、查询都会带来非常复杂的处理流程。而且性能也会有一些损耗。可以作为学习和研究的项目还是非常不错的。

       4.总结

       本文主要从日常需求出发，分析了日常业务过程中对本地缓存的需求，再调研了业界可选的一些组件并进行了对比，希望对本地缓存选型上起到一些参考和帮助。最后再对其中比较重要的几个组件如freecache、bigcache、fastcache、offheap等做了内部实现的简单介绍。上述内容只是从架构层面展开介绍，后续有时间再从源码层面做一些分析。由于篇幅限制本篇内容并未对map、sync.Map、go-cache、groupcache进行介绍。感兴趣的读者可以自行搜索资料进行阅读。如果大致理解了上述原理的童鞋也可以自己动手实践起来，造个轮子看看。

       5.参考资料

       欢迎点赞分享，关注 @鹅厂架构师，一起探索更多业界领先产品技术。