1.如何使用Ansible 2的API做python开发
2.wifi模块有哪些功能，它可以实现手机APP控制吗？
3.串口WIFI特点
4.学数据库以后可以做什么？

如何使用Ansible 2的API做python开发

       Ansible 和 SaltStack 都提供了 Python 直接调用的API, 这方便了 Pythoner 对这些软件进行二次开发和整合, 此功能着实方便了不少, 比起 Python 代码中调用 shell 也略显专业!

       ç„¶è€Œ Ansible 在2.0版本后重构了大部分的代码逻辑, 启用了2.0版本之前的 Runner 和 Playbook ç±», 使得广大同学之前的代码运行错误. 择日不如撞日, 今天中午对照 官方的文档 , 结合源代码, 对2.0版本之后的 Python API 做了下探究

       Adhoc

       adhoc 其实就是执行 Ansible 模块, 通过 adhoc 我们可以方便快捷的完成一些临时的运维操作.

       2.0 之前的调用

       import ansible.runner

       import json

       runner = ansible.runner.Runner(

        module_name='ping', # 模块名

        module_args='', # 模块参数

        pattern='all', # 目标机器的pattern

        forks=

        )

       datastructure = runner.run()

       data = json.dumps(datastructure,indent=4)

       å½“然这里会去加载默认的 inventory

       å¦‚果不想使用 inventory 文件或者想使用动态的 inventory, 则可以使用 host_list 参数代替

       import ansible.runner

       import json

       runner = ansible.runner.Runner(

        host_list=["..0.1"], # 这里如果明确指定主机需要传递一个列表, 或者指定动态inventory脚本

        module_name='ping', # 模块名

        module_args='', # 模块参数

        extra_vars={ "ansible_ssh_user":"root","ansible_ssh_pass":"xx"},

        forks=

        )

       datastructure = runner.run()

       data = json.dumps(datastructure,indent=4)

       2.0 之后的调用

       import json

       from ansible.parsing.dataloader import DataLoader

       from ansible.vars import VariableManager

       from ansible.inventory import Inventory

       from ansible.playbook.play import Play

       from ansible.executor.task_queue_manager import TaskQueueManager

       from ansible.executor.playbook_executor import PlaybookExecutor

       loader = DataLoader() # 用来加载解析yaml文件或JSON内容,并且支持vault的解密

       variable_manager = VariableManager() # 管理变量的类,包括主机,组,扩展等变量,之前版本是在 inventory 中的

       inventory = Inventory(loader=loader, variable_manager=variable_manager)

       variable_manager.set_inventory(inventory) # 根据 inventory 加载对应变量

       class Options(object):

        '''

        这是一个公共的类,因为ad-hoc和playbook都需要一个options参数

        并且所需要拥有不同的属性,但是大部分属性都可以返回None或False

        因此用这样的一个类来省去初始化大一堆的空值的属性

        '''

        def __init__(self):

        self.connection = "local"

        self.forks = 1

        self.check = False

        def __getattr__(self, name):

        return None

       options = Options()

       def run_adhoc():

        variable_manager.extra_vars={ "ansible_ssh_user":"root" , "ansible_ssh_pass":"xxx"} # 增加外部变量

        # 构建pb, 这里很有意思, 新版本运行ad-hoc或playbook都需要构建这样的pb, 只是最后调用play的类不一样

        # :param name: 任务名,类似playbook中tasks中的name

        # :param hosts: playbook中的hosts

        # :param tasks: playbook中的tasks, 其实这就是playbook的语法, 因为tasks的值是个列表,因此可以写入多个task

        play_source = { "name":"Ansible Ad-Hoc","hosts":"..0.1","gather_facts":"no","tasks":[{ "action":{ "module":"shell","args":"w"}}]}

        play = Play().load(play_source, variable_manager=variable_manager, loader=loader)

        tqm = None

        try:

        tqm = TaskQueueManager(

        inventory=inventory,

        variable_manager=variable_manager,

        loader=loader,

        options=options,

        passwords=None,

        stdout_callback='minimal',

        run_tree=False,

        )

        result = tqm.run(play)

        print result

        finally:

        if tqm is not None:

        tqm.cleanup()

       if __name__ == '__main__':

        run_adhoc()

       Playbook

       playbook 则类似于 SaltStack 中的 state

       2.0 之前的调用

       from ansible import callbacks

       from ansible import utils

       from ansible.playbook import PlayBook

       stats = callbacks.AggregateStats()

       callback = callbacks.PlaybookCallbacks()

       runner_callbacks = callbacks.PlaybookRunnerCallbacks(stats)

       pb = ansible.playbook.PlayBook(

        playbook="tasks.yml",

        stats=stats,

        callbacks=playbook_cb,

        runner_callbacks=runner_cb,

        check=True

       )

       pb.run()

       2.0 之后的调用

       import json

       from ansible.parsing.dataloader import DataLoader

       from ansible.vars import VariableManager

       from ansible.inventory import Inventory

       from ansible.playbook.play import Play

       from ansible.executor.task_queue_manager import TaskQueueManager

       from ansible.executor.playbook_executor import PlaybookExecutor

       loader = DataLoader() # 用来加载解析yaml文件或JSON内容,并且支持vault的解密

       variable_manager = VariableManager() # 管理变量的类,包括主机,组,扩展等变量,之前版本是在 inventory 中的

       inventory = Inventory(loader=loader, variable_manager=variable_manager)

       variable_manager.set_inventory(inventory) # 根据 inventory 加载对应变量

       class Options(object):

        '''

        这是一个公共的类,因为ad-hoc和playbook都需要一个options参数

        并且所需要拥有不同的属性,但是大部分属性都可以返回None或False

        因此用这样的一个类来省去初始化大一堆的空值的属性

        '''

        def __init__(self):

        self.connection = "local"

        self.forks = 1

        self.check = False

        def __getattr__(self, name):

        return None

       options = Options()

       def run_playbook():

        playbooks=['task.yaml'] # 这里是一个列表, 因此可以运行多个playbook

        variable_manager.extra_vars={ "ansible_ssh_user":"root" , "ansible_ssh_pass":"xxx"} # 增加外部变量

        pb = PlaybookExecutor(playbooks=playbooks, inventory=inventory, variable_manager=variable_manager, loader=loader, options=options, passwords=None)

        result = pb.run()

        print result

       if __name__ == '__main__':

        run_playbook()

wifi模块有哪些功能，它可以实现手机APP控制吗？

       WiFi模块又名串口WiFi模块，属于物联网传输层，功能是将串口或TTL电平转为符合Wi-Fi无线网络通信标准的嵌入式模块，符合IEEE. 协议栈网络标准，歌曲app源码内置TCP/IP协议栈，能够实现用户串口、以太网、无线网（WIFI）3个接口之间的任意透明转换，使传统串口设备更好的加入无线网络。

       通过串口WiFi模块 ，传统的串口设备在不需要更改任何配置的情况下，即可通过Internet 网络传输自己的数据。

       基于AP组建的基础无线网络(Infra)：Infra：也称为基础网，是由AP创建，众多STA加入所组成的无线网络，这种类型的网络的特点是AP是整个网络的中心，网络中所有的通信都通过AP来转发完成。

       安全机制：本模块支持多种无线网络加密方式，能充分保证用户数据的安全传输，包括：WEP/WEP/ TKIP/CCMP(AES) WEP/WPA-PSK/WPA2-PSK。

       快速联网：本模块支持通过指定信道号的方式来进行快速联网。在通常的无线联网过程中，会首先对当前的所有信道自动进行一次扫描，来搜索准备连接的目的AP创建的(或Adhoc)网络。本模块提供了设置工作信道的参数，在已知目的网络所在信道的条件下，可以直接指定模块的工作信道，从而达到加快联网速度的目的。

       地址绑定：本模块支持在联网过程中绑定目的网络BSSID地址的功能。根据.协议规定，不同的无线网络可以具有相同的网络名称(也就是SSID/ESSID)，但是必须对应一个唯一的BSSID 地址。非法入侵者可以通过建立具有相同的SSID/ESSID的无线网络的方法，使得网络中的STA联接到非法的AP上，从而造成网络的泄密。通过BSSID地址绑定的方式，可以防止STA 接入到非法的网络，从而提高无线网络的手机登录注册源码安全性。

       无线漫游：模块支持基于.协议的无线漫游功能。无线漫游指的是为了扩大一个无线网络的覆盖范围，由多个AP共同创建一个具有相同的SSID/ESSID的无线网络，每个AP用来覆盖不同的区域，接入到该网络的STA可以根据所处位置的不同选择一个最近(即信号最强)的AP来接入，而且随着STA的移动自动的在不同的AP之间切换。

       灵活的参数配置：

       1. 基于串口连接，使用配置管理程序

       2. 基于串口连接，使用Windows下的超级终端程序

        3.基于网络连接，使用IE浏览器程序

       4. 基于无线连接，使用配置管理程序。

串口WIFI特点

       串口WIFI技术以其独特的MAC+RF架构脱颖而出，它整合了无线通信功能，无需额外的微控制器(MCU)支持。硬件上，它内嵌了.协议，包括TCP/IP，确保了网络连接的稳定性和兼容性。

       串口WIFI设备具备广泛的网络协议支持，涵盖了TCP/UDP/ICMP/DHCP/DNS/HTTP等，使得它能够适应多种网络环境和应用需求。同时，它具备自动连接和工作命令模式，允许设备通过DHCP自动获取IP地址，简化了网络配置过程。

       在数据传输方面，串口WIFI支持透明传输模式，这意味着它能够在不改变原始数据结构的情况下进行传输，确保信息的完整性。此外，内置的WEB服务器使得设备可以通过浏览器进行远程配置，提供了极大的便利性。

       在安全层面，串口WIFI支持WEP/WEP/WPA-PSK/WPA2-PSK等多种加密方式，保障了网络连接的安全性。用户既可以选择预设的加密模式，也可以通过配置软件或IE浏览器定制参数，以满足个性化的安全需求。

       此外，拼多多 html源码串口WIFI技术兼容两种网络模式——基础网(Infra)和自组网(Adhoc)，前者依赖于已存在的Wi-Fi网络，后者则允许设备之间直接通信，扩展了网络覆盖范围。

       最后，串口WIFI设备还支持AT+编辑命令控制，便于开发者进行深入定制。它提供MCU控制的C源代码，这使得用户可以根据实际应用需要进行二次开发，灵活性极高。

学数据库以后可以做什么？

       只会写代码的是码农；

       学好数据库，基本能混口饭吃

；在此基础上再学好

       操作系统和计算机网络

，就能当一个不错的程序员。如果能再把离散数学、数字电路、体系结构、数据结构/算法、编译原理学通透，再加上丰富的实践经验与领域特定知识，就能算是一个优秀的工程师了。

       计算机

其实就是存储/IO/CPU三大件；而

       计算

说穿了就是两个东西：

       数据与算法（状态与转移函数）

。常见的软件应用，除了各种模拟仿真、模型训练、视频游戏这些属于

       计算密集型应用

外，绝大多数都属于

       数据密集型应用

。从最抽象的意义上讲，这些应用干的事儿就是把数据拿进来，存进数据库，需要的时候再拿出来。

       抽象

是应对复杂度的最强武器。操作系统提供了对存储的基本抽象：内存寻址空间与磁盘逻辑块号。文件系统在此基础上提供了文件名到地址空间的KV存储抽象。而数据库则在其基础上提供了

       对应用通用存储需求的高级抽象

。

       互联网应用大多属于

       数据密集型应用

，对于真实世界的数据密集型应用而言，除非你准备从基础组件的轮子造起，不然根本没那么多机会去摆弄花哨的数据结构和算法。甚至写代码的线上电玩城源码本事可能也没那么重要：可能只会有那么一两个AdHoc算法需要在应用层实现，大部分需求都有现成的轮子可以使用，主要的创造性工作往往在数据模型与数据流设计上。实际生产中，

       数据表就是数据结构，索引与查询就是算法

。而应用代码往往扮演的是

       胶水

的角色，处理IO与业务逻辑，其他大部分工作都是

       在数据系统之间搬运数据

。

       在最宽泛的意义上，

       有状态的地方就有数据库

。它无所不在，网站的背后、应用的内部，单机软件，区块链里，甚至在离数据库最远的Web浏览器中，也逐渐出现了其雏形：各类状态管理框架与本地存储。“数据库”可以简单地只是内存中的哈希表/磁盘上的日志，也可以复杂到由多种数据系统集成而来。

       关系型数据库只是数据系统的冰山一角

（或者说冰山之巅），实际上存在着各种各样的数据系统组件：

       数据库

：存储数据，以便自己或其他应用程序之后能再次找到（PostgreSQL，MySQL，Oracle）

       缓存

：记住开销昂贵操作的结果，加快读取速度（Redis，Memcached）

       搜索索引

：允许用户按关键字搜索数据，或以各种方式对数据进行过滤（ElasticSearch）

       流处理

：向其他进程发送消息，进行异步处理（Kafka，Flink，Storm）

       批处理

：定期处理累积的大批量数据（Hadoop）

       架构师最重要的能力之一，就是了解这些组件的性能特点与应用场景，能够灵活地权衡取舍、集成拼接这些数据系统。

绝大多数工程师都不会去从零开始编写存储引擎，因为在开发应用时，数据库已经是足够完美的工具了。关系型数据库则是目前所有数据系统中使用最广泛的组件，可以说是程序员吃饭的主要家伙，重要性不言而喻。性格标签是源码

       对玩具应用而言，使用内存变量与文件来保存状态也许已经绰绰有余了。但随着系统的增长，我们会遇到越来越多的挑战：软硬件故障把数据搞成一团浆糊（可靠性）；状态太多而内存太小放不下（可伸缩性）；并发访问控制导致代码复杂度发生爆炸（可维护性），诸如此类。这些问题相当棘手，却又相当普遍，数据库就是用来解决这些问题的。

       分拆

是架构演化的重要方法论，数据库将

       状态管理

的职能从应用程序中分拆出来，即所谓的“状态与计算相分离”。数据库将程序员从重复造轮子的泥潭中解救出来，极大地解放了生产力。

       每个系统都服务于一个目的，解决一类问题。

       问题比方法更重要

。但现实很遗憾，以大多数学生，甚至相当一部分公司能接触到的现实问题而言，拿几个文件甚至在内存里放着估计都能应付大多数场景了（需求简单到低级抽象就可以Handle）。

       没什么机会接触到数据库真正要解决的问题，也就难有真正使用与学习数据库的驱动力，更别提数据库原理了

。

       所以我也理解当前这种填鸭教学现状的苦衷：工作之后很难有这么大把的完整时间来学习原理了，所以老师只好先使劲灌输，多少让学生对这些知识有个印象。等学生参加工作后真正遇到这些问题，也许会想起大学好像还学了个叫

       数据库

的东西，这些知识就会开始反刍。

       数据库，尤其是关系型数据库，非常重要。那为什么要学习其原理呢？

       对

       优秀

的工程师来说，只会

       用

数据库是远远不够的。学习原理对于当CRUDBOY搬砖收益并不大，但当

       通用组件真的无解

需要自己撸起袖子上时，没有金坷垃怎么种庄稼？设计系统时，

       理解原理能让你以最少的复杂度代价写出更可靠高效的代码；遇到疑难杂症需要排查时，理解原理能带来精准的直觉与深刻的洞察。

       数据库是一个博大精深的领域，存储I/O计算无所不包。其主要原理也可以粗略分为几个部分：数据模型设计原理（应用）、存储引擎原理（基础）、索引与查询优化器的原理（性能）、事务与并发控制的原理（正确性）、故障恢复与复制系统的原理（可靠性）。 所有的原理都有其存在意义：为了解决实际问题。

       例如

       数据模型设计中

的

       范式理论

，就是为了解决

       数据冗余

这一问题而提出的，

       它是为了把事情做漂亮（可维护）

。它是模型设计中一个很重要的设计权衡：通常而言，

       冗余少则复杂度小/可维护性强，冗余高则性能好

。具体来说，冗余字段能加快特定类型的读取（通过消除连接），但在写入时就需要做更多的工作：维护多对象副本间的一致性，避免多对象事务并发执行时发生踩踏。这就需要仔细权衡利弊，选择合适的规范化等级。

       数据模型设计，就是生产中的数据结构设计

。

       不了解这些原理，就难以提取良好的抽象，其他工作也就无从谈起。

       而

       关系代数与索引

的原理，则在查询优化中扮演重要的角色，

       它是为了把事情做得快（性能，可扩展）

。当数据量越来越大，SQL写的越来越复杂时，它的意义就会体现出来：

       怎样写出等价但是更高效的查询？

当查询优化器没那么智能时，就需要人来干这件事。

       这种优化往往有四两拨千斤的效果

，比如一个需要几秒的KNN查询，如果知道R树索引的原理，就可以通过

       改写查询

，创建GIST索引优化到1毫秒内，千倍的性能提升。

       不了解索引与查询设计原理，就难以充分发挥数据库的性能。

       事务与并发控制的原理，

       是为了把事情做正确

。事务是数据处理领域最伟大的抽象之一，它提供了很多有用的保证（ACID），

       但这些保证到底意味着什么？

事务的

       原子性

让你在提交前能随时中止事务并丢弃所有写入，相应地，事务的

       持久性

则承诺一旦事务成功提交，即使发生硬件故障或数据库崩溃，写入的任何数据也不会丢失。这让错误处理变得无比简单，所有可能的结果被归结为两种情况：

       要么成功完事，要么失败了事（或重试）

。有了后悔药，程序员不用再担心半路翻车会留下惨不忍睹的车祸现场了。

       另一方面，事务的

       隔离性

则保证同时执行的事务无法相互影响（在可序列化隔离等级下）。更进一步，数据库提供了不同的隔离等级保证，以供程序员在

       性能与正确性之间进行权衡

。编写并发程序并不容易，在几万TPS的负载下，各种极低概率，匪夷所思的问题都会出现：事务之间相互踩踏，丢失更新，幻读与写入偏差，慢查询拖慢快查询导致连接堆积，单表数据库并发增大后的性能急剧恶化，比如我遇到的一个最灵异的

       例子

是：快慢查询总量都减少，但因相对比例变化导致数据库被压垮。这些问题，在低负载的情况下会潜伏着，随着规模量级增长突然跳出来，给你一个大大的惊喜。现实中真正可能出现的

       各类异常

，也绝非SQL标准中简单的几种异常能说清的。

       不理解事务的原理，意味着应用的正确性与数据的完整性可能遭受不必要的损失。

       故障恢复与复制

的原理，可能对于普通程序员没有那么重要，但架构师与DBA必须清楚。高可用是很多应用的追求目标，但什么是高可用，高可用怎么保证？读写分离？快慢分离？异地多活？x地x中心？说穿了底下的核心技术其实就是

       复制（Replication）

（或再加上

       自动故障切换（Failover）

）。这里有无穷无尽的坑：

       复制延迟

带来的各种灵异现象，

       网络分区

与

       脑裂

，

       存疑事务

，诸如此类。

       不理解复制的原理，高可用就无从谈起。

       对于一些程序员而言，可能数据库就是“增删改查”，包一包接口，原理似乎属于“屠龙之技”。如果止步于此，那原理确实没什么好学的，但有志者应当打破砂锅问到底的精神。私认为只了解自己本领域知识是不够的，只有把当前领域赖以建立的上层领域摸清楚，才能称为专家。在数据库面前，后端也是前端；对于程序员的知识栈而言，数据库是一个合适的栈底。

       上面讲了

       WHY

，下面就说一下

       HOW

       数据库教学的一个矛盾是：

       如果连数据库都不会用，那学数据库原理有个卵用呢？

       学数据库的原则是

       学以致用

。

       只有实践，才能带来对问题的深刻理解；只有先知其然，才有条件去知其所以然。

教材可以先草草的过一遍，然后直接去看数据库文档，上手去把数据库用起来，做个东西出来。通过实践掌握数据库的使用，再去学习原理就会事半功倍（以及充满动力）。对于学习而言，有条件去实习当然最好，没有条件那最好的办法就是

       自己创造场景，自己挖掘需求。

       比如，从解决个人需求开始：管理个人密码，体重跟踪，记账，做个小网站、在线聊天App，实用微信小程序。当它演化的越来越复杂，开始有多个用户，出现各种蛋疼问题之后，你就会开始意识到

       事务

的意义。

       再比如，结合爬虫，抓一些房价、股价、地理、社交网络的数据存在数据库里，做一些挖掘与

       分析

。当你积累的数据越来越多，分析查询越来越复杂；SQL长得没法读，跑起来慢出猪叫，这时候关系代数的理论就能指导你进一步进行优化。

       当你意识到这些设计都是为了解决现实生产中的问题，并亲自遇到过这些问题之后，再去学习原理，才能相互印证，并知其所以然。当你发现查询时间随数据增长而指数增长时；当你遇到成千上万的用户同时读写为并发控制焦头烂额时；当你碰上软硬件故障把数据搅得稀巴烂时；当你发现数据冗余让代码复杂度快速爆炸时；你就会发现这些设计存在的意义。

       教材、书籍、文档、视频、邮件组、博客都是很好的学习资源。教材的话华章的黑皮系列教材都还不错，《数据库系统概念》这本就挺好的。但我推荐先看看这本书：

       《设计数据密集型应用》

，写的非常好，我觉得不错就义务翻译了一下。

       纸上得来终觉浅，绝知此事要躬行。写了这么多，不带点“

       私货

”也不合适哈？实践方能出真知，新手上路选哪家？我个人推荐PostgreSQL，如果能再选一样就加个Redis。对开发而言，这是相当实用的组合。PostgreSQL号称世界上

       最先进的开源关系型数据库

，源代码写的非常漂亮，有很多值得学习的地方。很多国外的数据库课程与教科书都使用PostgreSQL作为教学样例。

       PostgreSQL在现实世界中也表现不俗，在我们的实践中，在WTPS与TB数据的量级下，

       单一PostgreSQL选型

依然能稳如狗地支撑业务。而且其功能

       丰富到不可思议

，能在很可观的规模内做到一专多长，除了本职的OLTP，Pg还在相当长的时间里兼任了缓存，OLAP，批处理，甚至消息队列的角色。当然如“架构演进”一图所示，神龟虽寿，犹有竟时。最终这些兼职功能还是要逐渐

       分拆

出去由专用组件负责，但那已经是近千万日活时的事了。

       所以，关系型数据库虽然强大，却绝非数据处理的终章。数据库的世界非常精彩，尽可能地去尝试各种各样的组件吧~。