B端C端产品的对比

行业和场景需求

B端：针对某个特定行业，解决某个环节的流程问题

• 对程序和产品的要求：与客户群体沟通，了解痛点和业务需求，才能做出真正贴合企业运营的设计

C端：可适应多个场景，需考虑不同用户需求，业务线会较长

• 对程序和产品的要求：大部分要求较低，业务过多人员多，团队管理和配合方面难度可能会上升
• 没有明显的行业特征，更多的是考虑流传度和用户粘度，需要渗透进用户生活的方方面面。

展示方式和技术栈

B端：主要是web pc端和桌面应用程序

前期时，服务端人员可使用现成的各种管理后台模板 主要要求对于数据和逻辑的处理，前端样式要求不高

C端：主要是web 手机端+小程序+APP+自助大屏机器

面向大量消费者群体，需要专门设计和前端更好贴合市场和品牌形象

盈利运营模式

B端：靠企业对“定制付费”来获得收益。

• 通过树立行业级别内的“专业形象”来吸引企业客户的兴趣

C端：提供实惠、免费的基础功能，再通过“拉新、留存、促活”等手段，转化其中一小部分用户为付费用户。品牌知名度等

• 以利益激励用户主动在线上进行“对外分享传播”

GIT Workflow

作为项目代码版本管理，在团队中不同成员工作成果合并并发布的方式不同，对分支的使用（工作流）也不同

记录一下个人理解常见的几种方式

git wordflow

适用于：固定版本发布日期周期的团队（多个功能一次性上线）

分支情况：

• master分支
• dev分支
• • 提测功能测试完成之后合并到release分支
• release分支
• • 预发布环境，可能预发布后还有新的小bug 继续修复 稳定后合并到master分支
• feature分支（业务开发分支）
• • 从dev分支新建
• • 开发完成之后合并到dev分支

前言 写了一个油猴脚本处理一些其他网站的订单采集到自己的系统，采集页面dom的数据,然后使用clipboard.min.js复制 由于网站逻辑问题,不可以直接注入复制按钮,只可以JS逻辑处理后使用prompt()方法 把数据放在对话框中复制 此时会有长度问题, 订单数量一旦超过一定数量，pr ...

先切换checkout目标分支 在GIT面板中 选中来源分支 在来源分支的git commit 上右键 点击[优选]

校验密码强度 //1) 是否包含小写字母 $pattern = '/[a-z]+/'; $res = preg_match($pattern, $password); //2) 是否包含大写字母 $pattern = '/[A-Z]+/'; $res2 ...

在宝塔的网站--设置--伪静态 写入以下代码

注意：需要填写在thinkphp的伪静态隐藏index.php规则之前

location ~* (.*)\.(gif|jpg|jpeg|png|bmp|swf)!(\d+)x(\d+)_(\d+)$ {
    expires      30d;
    error_log /dev/null;
    access_log /dev/null;

    set $w $3;
    set $h $4;

    # crop裁剪 resize缩放
    image_filter resize  $w $h;
    image_filter_buffer  100M;
    image_filter_jpeg_quality $5;
    try_files /$1.$2 /404.jpg;
}

访问图片路径 就可以扩展为 536de782104cc8edcdfc7e9bd29a3757.jpg!800x800_80 自定义尺寸和压缩比例

问题背景 dtm中的子事务屏障，需要与数据库交互，xa事务模式，也需要与数据库交互。 根据部署文档RM数据库的导入教程，出现以下报错 Specified key was too long; max key length is 1000 bytes 解决 创建表的mysql脚本没有指定存储引擎 ...

问题背景 在使用saga分布式事务的时候，接口执行时间过长，导致 dtm-server多次重发 请求到节点 在dtm文档中，关于超时的说明如下 saga属于长事务，因此持续的时间跨度很大，可能是100ms到1天，因此saga没有默认的超时时间。 dtm支持saga事务单独指定超时时间，到了 ...

前言

win10下，docker启动了apisix dashboard容器，浏览器和CURL命令获取容器服务都失败, curl http://127.0.0.1:9000

排查思路

• 检查容器是否启动正常
• 检查容器端口配置映射是否正常
• 检查宿主机端口是否开启正常
• 检查宿主机端口占用进程

前言

一直在网上文章看到kafka是磁盘顺序写，所以效率更高，但是从磁盘的物理设计来考虑，又不可能真正的顺序，一直很纠结，找了一些资料，简单记录

kafka

因为Kafka消息在使用时不会被删除（就像在其他消息代理中一样）Kafka不会通过不断创建和删除许多变量长度来创建碎片文件系统文件。相反，它会创建段文件，然后附加到该文件，直到达到1GB（可配置的限制）

建议最佳做法是将这些Kafka提交日志文件保存在专用文件系统上，以免其他应用程序读取和写入可变长度文件到同一文件系统中。

rabbitMQ

rabbitMQ对于可靠性的设计更好，有ack消息确认机制，当ack消息确认后，该消息从队列删除，不管是真正的磁盘删除还是修改消息状态，都要涉及到文件的寻址，所以会稍慢.