白菜君の技术库

前言

上一篇《mock服务架构设计（一）》中，我们发现

前言

在公司的日常adx开发流程中，我发现其中一个很费心，很费时的行为，那就是要拿到上游的广告offer。

要拿到一个正常的offer，不单单需要匹配内部的逻辑，还要看上游是否需要对你的这次展示机会进行竞价。

由于在adx的业务逻辑中，一次请求会同时请求N次上游，所以必然少不了对上游的询价(请求)行为，那我们在日常开发，以及做代码调试的过程中，有没有办法可以更好的做到能拿到offer来对我们的竞价行为进行调试和开发呢？

还有一种场景就是测试同学会面临的，就是如何在尽量不影响线上数据的情况下，能安全无痛的进行测试adx呢，如果因为测试的行为，导致线上业务数据异常，或者出现了结算问题，对于大规模流量的广告自动化交易程序来说，这都是致命的，严重点来说，可能随时导致破产。

又换句话说，有没有办法能在我们想要做模拟压测的时候，也能进行正常的内部逻辑呢？其中一个难点就是我们在压测的环节，并不想正式去对上游询价，但是我又想要拿到上游的offer，除了 hard code offer的动作外，有没有一些更理想的架构方案呢？

答案是：有的，接下来就是我们的主题

前言

前面做了几期关于Home assistant的教程，在前面我是完全使用docker手动部署，并且采用基本都是通过安装home-assistant-core去处理。后面我发现很多东西的使用方式都特别别扭，而且确实很多东西都比较麻烦，所以后面再反过来看，发现了一个叫hass的生态，这个其实就是home-assistant的周边生态，而这些周边，几乎都是必备的，于是我妥协了使用了hass的生态，但是有一点不同的是，我这里并没有使用hassOS，而是采用hassIO，也就是home-assistant-supervisor。

下面开始，我就会我的正式体现记录我后面的智能家居做法。

前言

最近在处理ssp-adx-rtb的服务的性能优化，做了好多方面的优化，其中一个就是我们的本地的localcache的问题。

经过pprof的性能分析，发现cache2go，在 CPU Flame Graph 中，占比十分严重，基本大于1/3，既然是localcache，那么，我们的目的本意就是为了提速，所以占比那么大，是十分不合理的。

所以需要找到原因，并且解决它。降低cpu使用率，从而提高服务的QPS，减少服务器成本。

前言

本次主要是讲解一下进阶版的HA，为什么说是进阶版本呢，因为我也是花了几天的时候，去了解各种知识才了解得到的内容。

内容包括：什么叫hassio，hassos，并且他们和Home Assistant 是什么关系。

并且我会重点讲解docker版本的HA都是需要怎么玩（不借助hassio），你问我为什么，我就告诉你因为过于繁琐，并且多了很多无用的容器占用系统资源。

为什么我偏执于docker版本的ha？因为我不想一台机器，只做一件事，这对高配置和高性能的机器是一种绝对的浪费。

在这个时候，环境隔离就成了重要的因素, 而docker就很好的做到了这一点，并且不像hassio的底层依赖。

前言

既然是技术博客，那么这一期，我会开始做一系列的关于智能家居的玩法。

Home Assistant 也叫 HA + Zigbee协议(硬件之间的通信协议)

HACS 是 HA 的一个第三方插件，这个插件包括了许多开发者所贡献的插件，如果你是一名开发人员，那么你一定了解什么叫依赖库。所以可以理解为 HACS 就是 HA 的第三方插件依赖库，你可以在连找到需要对你有用的插件，而你不必重新开发。

为什么选择 Zigbee协议 ？ 在对比过蓝牙mesh,wifi协议之后，我最终选择了zigbee协议，在于硬件之间的控制信号量传输本身就少，所以它自身的稳定性和分布式的特点，可以很好的支持到家庭中的各个角落，不会出现由于信号差导致失灵的情况，并且zigbee协议的特点，电量的消耗也是十分的低。

前言

音频中的audio有很多格式，分别有aac,mp3等等

在海外市场中，aac格式比较普遍，所以最近对其进行了一些研究。

前言

由于广告行业有众多的知识点，所以记录一篇文章用以了解相关的专业名词和术语，并且加深了解的印象。

前言

最近，准备重新打造我的mac电脑。

前言

现在，git已经成为了大家的代码仓库管理的一个工具了。在日常工作，我们会遇到各种个样的git问题，因此，用一篇文章来累计记录，日常生活中，我们会遇到，但是不常用的命令。