1.cloud-init介绍及源码解读(上)
2.Python 爬虫进阶篇——diskcahce缓存(二)
3.Windows11+Metis5.1.0 gpmetis 自动源码bug问题

cloud-init介绍及源码解读(上)

       cloud-init介绍及源码解读(上)

       cloud-init的基本概念

       metadata包含服务器信息，如instance id，分区分区display name等。源码userdata包含文件、开源脚本、工具yaml文件等，自动码云网站源码用于系统配置和软件环境配置。分区分区datasource是源码cloud-init配置数据来源，支持AWS、开源Azure、工具OpenStack等，自动定义统一抽象类接口，分区分区所有实现都要遵循规范。源码

       模块决定定制化工作，开源metadata决定结果。工具cloud-init配置有4个阶段：local、network、config、final。java源码 异构数据cloud-init支持多种userdata类型，如自定义Python代码、MIME文件等。用户数据类型包括User-Data Script（MIME text/x-shellscript）和Cloud Config Data（MIME text/cloud-config）。

       cloud-init支持多种datasource，包括NoCloud、ConfigDrive、OpenNebula等。通过Virtual-Router获取metadata和userdata信息。

       cloud-init在云主机上创建目录结构以记录信息。cloud.cfg文件定义各阶段任务。

       cloud-init工作原理

       cloud-init通过从datasource获取metadata，执行四个阶段任务完成定制化工作。在systemd环境下，这些阶段对应的服务在启动时执行一次。

       local阶段从config drive中获取配置信息写入网络接口文件。network阶段完成磁盘格式化、分区、网页游戏 外挂 源码挂载等。config阶段执行配置任务。final阶段系统初始化完成，运行自动化工具如puppet、salt，执行用户定义脚本。

       cloud-init使用模块指定任务，metadata决定结果。set_hostname模块根据metadata设置主机名。设置用户初始密码和安装软件是典型应用。

       cloud-init源码解读

       cloud-init核心代码使用抽象方法实现，遵循接口规范。主要目录包括定义类和函数、网络配置、模块初始化、系统发行版操作、配置文件管理、模块处理、DNF源码yy频道数据源、事件报告等。

       模块通过handle函数解析cloud config配置，并执行逻辑。数据源类扩展实现接口。handler处理用户数据。reporting框架记录事件信息。

       cloud-init提供文件操作、日志管理、配置解析等辅助类。其他文件包括模板处理、日志格式定义、版本控制等。

       cloud-init通过模块、datasource和配置文件实现云主机元数据管理和定制化。源码结构清晰，功能全面，是pcshare 易语言 源码云环境定制的强大工具。

Python 爬虫进阶篇——diskcahce缓存(二)

       上一篇文章为大家介绍了diskcache的基础用法，本文将继续深入探讨diskcache的更多高级功能。

       关于diskcache，它是一种基于SQLite数据库的缓存对象管理方式。SQLite是一个轻量级的基于磁盘的数据库，它不需要单独的服务器进程，并支持SQL查询。在上篇文章的源码截图上，你可以看到一些SQL语句的使用。

       diskcache支持使用diskcache.FanoutCache自动分片基础数据库。分片是对数据进行水平分区，可以减少写入时的阻塞。尽管读和写不会互相阻碍，但写入会阻碍其他写入。分片的默认值为8。

       以下是一个示例代码：

       # 示例代码

       在示例中，我们在diskcache_2文件夹中创建了一个具有四个分片和一秒超时的缓存。如果操作耗时超过一秒，它们将尝试中止操作。

       那么每一个分片的大小是多少呢？分片的大小都是平均分配的，占总空间的四分之一。diskcache的默认大小为1GB。

       diskcache提供了一个collections.deque兼容的双端队列diskcache.Deque。双端队列是堆栈和队列的一般化，可以在前后都可以进行快速访问和编辑，且可持久化，操作比较便捷。

       以下是一个示例代码：

       # 示例代码

       运行结果如下：

       Popleft 获取队列最前面的一个元素，pop获取末尾的一个元素；

       Appendleft 在队列最开始添加一个元素，append 在末尾添加一个元素；

       Extendleft 在队列最开始添加一个数组，extend在末尾添加一个数组；

       那么deque的存储位置在哪里？可以使用以下命令查看队列的存储位置：

       包括cache也是一个可以使用directory属性查看默认存储的位置；

       那么如何指定directory呢？Deque的第二个参数指定存储位置，第一个参数为队列的初始值。或者可以直接指定参数名称，如下：

       Index 类似于dict(字典)，可持久化，使用也比较便捷。以下是一个示例：

       # 示例代码

       popitem表示获取最后一个键对值，并且删除，结果如下：

       peekitem() 可传递last 参数是否获取最后一个，不会删除原始值；

       setdefault(key,default) 可以给指定的key值设置默认值，在查找时可以预先设置一个默认值，防止key值不存在而抛出异常。

       keys()与values()可以查找所有Index中的key值与value值，然而没有提供判断key值是否存在的方法，但是可以使用setdefault的方法自行封装。

       Lock还记得上篇文章中提到的Lock锁吗？先看一下源码：

       可以看到这里的锁用的就是cache的add方法的特性，源码中也给出了使用的方式：

       从源码上看有一个while 死循环，直到add成功时才会被释放，这里处理的方式不是很好，可能会造成死锁，所以一般情况下，都会添加一个过期的时间，如下：

       RLock还有一种RLock锁，与Lock锁的区别是RLock允许在同一线程中被多次acquire。而Lock却不允许这种情况。以下是一个示例：

       结果是执行成功。

       看一下源码：

       从源码中可以看出，判断锁的条件是os.getpid()（进程pid）与threading.get_ident()（线程标识符），如果每次acquire时的pid与ident都相同的时，即可成功。那么就可以在相同的进程中无限次数的acquire,但是多少次acquire就得多少次的release,防止死锁。

       那么是使用Lock还是RLock呢？这个要具体的看实际情况，并不是谁就一定好。

       总结本次推文中介绍了diskcache中FanoutCache缓存分片、双端队列deque、Index、Lock以及RLock。

       大家可以在实际中灵活运用，diskcache缓存的优势还是很大的，无需安装其他的模块，并且在文件管理器中能直接查看，还可以利用缓存的一些特性使用多线程的去实现业务等。

       但是也是有缺点的，即受制于本地文件系统的限制。每个磁盘每个目录下的文件数量是有限制的，所以需要结合实际情况使用。

Windows+Metis5.1.0 gpmetis 源码bug问题

       运行编译后的 gpmetis.exe 命令，预期应生成分区文件，但实际操作中却未能如愿，输出文件并未出现。

       执行命令：

       .\gpmetis.exe .\4elt.graph 4

       结果并未产生文件，如预期的 4elt.graph.4 等分区文件。

       深入代码追踪，困惑与不解随之而来。VS 提供的线索指向了异常的栈使用，这似乎与问题的根源相关。

       经过细致排查，发现是数组的开辟过大，这并非必要，文件名的长度不至于如此。

       对代码进行调整，修改数组的开辟大小。

       调整后，程序能够正常输出信息，并生成预期的分区文件，如 4elt.graph.part.4。

       此问题的解决为类似错误的处理提供了参考，修正方法可适用于其他情况。

       本文档旨在记录并分享这一问题的解决过程，以供相关开发者参考与借鉴。