协议产生背景

MQTT (Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于TCP/IP网络协议栈的应用层协议。MQTT最开始是1999年IBM公司用于通过卫星通信连接石油管道监测系统而创造的协议。
这种场景的特点是：

2023.07.17收到了百度开源IoT Broker的好消息，一直没有时间看。最近工作闲下来了，准备分析一下它的实现。

2019年开发Broker时，调研了很多实现方式，百度IoT是我特别想参考的实现，只可惜当时并没有开源代码可以参考，通过对实现方式的猜测，总结了这篇文章：《百度IoT：MQTT Broker架构设计》，不过现在开源版本改动了很多东西。

假设应用1给应用2提供了一个接口，需要更新参数，将Map变为List<Map>，很容易写出这样的兼容代码：

1
2
3
4
5
6
7
8
9
10
11

@Data
public static class OldClass {
    private Map<String, String> bbbb;
}

@Data
public static class NewClass {
    private List<Map<String,String>> aaaa;
    @Deprecated
    private Map<String, String> bbbb;
}

然而在部署后发现，应用2拿到的数据对象中的bbbb，没有任何数据。

最近想添加封面图，想尝试使用StableDiffusion的AIGC自动生成封面图。但是，国内chatGPT很容易被封，像DALL·E这种又没法注册，国内百度的文言一格等未开放API，所以只有使用开源大模型了。

类似github管理代码仓库一样，比较有名的管理开源大模型的网站主要有2个：

• 国外：huggingface
• 国内：ModelScope（阿里合作）

考虑到第一次使用，学习曲线需要比较平缓才好入门，我使用国内的ModelScope来做大模型HelloWorld。最终决定使用阿里达摩院提供的中文StableDiffusion-通用领域这个大模型进行生成。

一、和之前“人工智障”的差异在哪里

1、能联系上下文，并不是一问一答，而是连续对话。

天猫精灵这类初代AI，只能做“天气如何”-“今天的天气是”，“今天几号”-“今天是”，这样一问一答的对话。但是一次问答通常只能“查询属性”、“执行命令”这种简单操作，人类的任务通常更复杂，需要分析对方答案并再次提出问题，直到双方观点对齐。chatGPT能够分析上下文，提供了连续问答的能力，所以现在有很多玩法是，让chatGPT扮演某个角色，然后以角色身份进行交互。

2、能够自我纠错，“你这里错了”，且具有主见，“我认为没有错”。

在连续对话的能力下，我们可以指出chatGPT答案中的错误，chatGPT会分析自己答案中的错误，并以更大的正确概率去修正答案。为什么通过指出错误能得到更正确的答案？目前的主流观点认为，这样做相当于把大任务划分为了小任务，单步拆解能给到更好的提示，辅助下一步的推理形成良性循环，因此最终大任务也具有更高的正确率了。

很多产品都会有积分系统：用户通过一定的行为累积积分，积分可以兑换各种权益，积分可能
会有增加（获取）、扣减（消耗）、查询余额、查看历史、过期、冻结等行为。

需求分析

1、积分过期的两种场景

积分过期是一种很常见的产品功能，因为一般都不希望用户累计大量积分，造成预算不可控。
过期有2种方式：

• 统一时间过期：比如今年所有获得的积分，都在今年年末过期
• 单笔时间过期：比如“A渠道获取的积分，3个月后过期”、“B渠道获取的积分，7天后过期”。

业务场景分析

通常业务都有控制预算或疲劳度的需求：

• 预算：每天最多发放N张优惠券、每月最多发放价值1000元的金币，……
• 疲劳度：每小时最多曝光N次，每个用户每天最多展示N次，……
  本质抽象出来，就是属于“限流”中的“计数器模型”，在指定时间段内，请求数量累加，有数量的最大限制。

整体思路分析

一、问题场景

在产品开发，通常会有这样的场景：

• 投放这个特效，用户更愿意购物，还是不投放这个特效，用户更愿意购物？
• 这个按钮用红色，男生用户更愿意点击，还是用绿色，男生用户更愿意点击？
• 优惠券面额满300减30，新用户更愿意下单，还是满100-10，新用户更愿意下单？

问题可以归纳为：为了达成某个目标，有多种方案可以选择时，如何进行决策？
正确的做法是数据驱动，让用户来体验，看他们是用手点赞还是用脚投票，帮助进行决策。

一、社交游戏

简单来说，就是拼多多砍一刀，今日头条极速版签到领金币。
用户付出社交关系，收获一些优惠券、现金奖励；平台付出资金，收获APP渗透率、购物用户、活跃用户、新用户。
场景有很多，比如：

• 签到类：签到换积分，积分换钱券
• 冲关类：多个关卡，冲关完成游戏得奖励，游戏通常需要做一些分享、助力的操作
• 组队类：和好友组队一起玩
• 走路类：走路、按时吃饭、按时睡觉得权益 —— 其实是为了促进活跃用户，让你吃饭睡觉都去看一眼
• 老带新类：老人拉新人，双方都得奖
• 答题类：答题得积分，积分换钱券
• 抽奖类：拉人，互动，定时开奖 —— 比如支付宝扫福瓜分5亿，其实让你加了支付宝好友并互动了

摇一摇功能分2种：

• 单纯的触发机制：拼多多摇一摇更换推荐商品、今日头条摇一摇得红包
• 需要进行匹配：微信摇一摇匹配附近的人，陌陌摇一摇匹配附近的朋友

在接到摇一摇需求的时候需要仔细分析业务需求。如果是第1种，只是单纯的触发机制，要是前端的工作，无论是什么形式，最后都只是一个单纯的请求而已。如果是第2种，就较复杂，需要详细设计匹配算法。

和摇一摇匹配类似的场景还有：滴滴司机乘客匹配、饿了么顾客骑手匹配、王者荣耀游戏匹配。