今年疫情造就了社区团购的死灰复燃，并且随着各大厂的杀入，直接变成风口了
目前入局的有：
滴滴 - 橙心优选
美团 - 美团优选
拼多多 - 多多买菜
老品牌有：
兴盛优选、十荟团、食享会 等
这个赛道，我理解有两个核心：团长运营、供应链
其实这两块对于新入局的大厂来讲都是没有什么基础的，而且都是前期需要巨额资金的，所以谁胜谁负不好说
但由于大厂的资金雄厚，可以烧钱，所以对于这些老品牌带来的压力是巨大的，如果老品牌不跟着烧钱，那你的团长和供应链都会被搞走，总体是很危险的
具体谁能成为王者，拭目以待吧。
给定一个数组，它的第 i 个元素是一支给定的股票在第 i 天的价格。
设计一个算法来计算你所能获取的最大利润。你最多可以完成 两笔 交易。
注意: 你不能同时参与多笔交易（你必须在再次购买前出售掉之前的股票）。
示例 1:
输入: [3,3,5,0,0,3,1,4]
输出: 6
解释: 在第 4 天（股票价格 = 0）的时候买入，在第 6 天（股票价格 = 3）的时候卖出，这笔交易所能获得利润 = 3-0 = 3 。
随后，在第 7 天（股票价格 = 1）的时候买入，在第 8 天 （股票价格 = 4）的时候卖出，这笔交易所能获得利润 = 4-1 = 3 。
示例 2:
输入: [1,2,3,4,5]
输出: 4
解释: 在第 1 天（股票价格 = 1）的时候买入，在第 5 天 （股票价格 = 5）的时候卖出, 这笔交易所能获得利润 = 5-1 = 4 。
注意你不能在第 1 天和第 2 天接连购买股票，之后再将它们卖出。
因为这样属于同时参与了多笔交易，你必须在再次购买前出售掉之前的股票。
示例 3:
输入: [7,6,4,3,1]
输出: 0
解释: 在这个情况下, 没有交易完成, 所以最大利润为 0。
解法
#include <stdlib.h>
#include <stdio.h>
int max_profit(int* list, int len);
#define MAX(a, b) ((a) > (b) ? (a) : (b))
int main()
{
// int list[] = {1,2,3,4,5};
// int list[] = {3,3,5,0,0,3,1,4};
// int list[] = {7,6,4,3,1};
// int list[] = {1,2,4,2,5,7,2,4,9,0};
// int list[] = {8,3,6,2,8,8,8,4,2,0,7,2,9,4,9};
// int list[] = {3,2,6,5,0,3};
int list[] = {1,2,4,2,5,7,2,4,9,0};
int len = sizeof(list) / sizeof(int);
int ret = max_profit(list, len);
printf("max %d\n", ret);
}
int max_profit(int* list, int len)
{
if(len < 2) {
return 0;
}
int dp0 = 0;
int dp1 = 0 - list[0];
int dp2 = 0;
int dp3 = 0 - list[0];
int dp4 = 0;
for(int i=1; i<len; i++) {
dp1 = MAX(dp1, dp0 - list[i]);
dp2 = MAX(dp2, dp1 + list[i]);
dp3 = MAX(dp3, dp2 - list[i]);
dp4 = MAX(dp4, dp3 + list[i]);
}
return MAX(0, MAX(dp1, MAX(dp2, MAX(dp3, dp4))));
}最近突然听起了校园歌曲
想到了自己的高中、大学生活好像也没留下太多深刻的回忆，不像很多电视或者别人描述的那么多姿多彩
不过听起了这些校园歌曲，还是特别的有感觉
最后吐槽下QQ音乐的歌单，一般都只有10几首
不像网易云音乐，一个歌单可以有上百首歌曲
但网易云音乐里的很多音乐都没有版权，播放不了
从07年开始正式进入互联网行业，真是见证了一拔又一拔的互联网浪潮，也无一例外的没抓住任何一次，之前一直归为运气不佳，实则是能力太差。
刚入互联网的时候，马上就是社交网络的兴起，见证了校内到人人、见证了QQ空间，尤其是Facebook的开放平台概念出来后，一头扎进了开放平台应用的开发中，一开始是一些小的工具内的应用，到后面被证明还是游戏传播性、收益最大，于是乎，偷菜一夜席卷整个互联网，作者也投身这个方向，做过几个大几百万DAU的游戏，但最终还是没能抓住逆袭翻身的机会，遗憾错过了这一拔，但也见证了身边很多的屌丝盆友，屌丝团队逆袭，比如：智明星通、胡莱、恺英、博雅等等
而后接下来是一拔O2O的浪潮，从千团大战到洗车、美甲、吃饭、出行等等，一时是满大街的扫码，这一拔最终成就了美团，滴滴等目前的巨头，其他的都基本烟消云散，当时有机会加入美团前身的饭否团队，又是遗憾的错过了这一个大机会。
接下来是轰轰烈烈的互联网金融浪潮了，但如今已经是一地鸡毛，当时入场了很短的一段时间，选择的赛道是校园分期，这个赛道反而跑出来了两家：趣店和分期乐，话说当时趣店和分期乐当时竞争还是很激烈了，当时我们创业的一开始也做的不错，后面有人撮合我们和趣店合并，如果合并成功，月GMV就会超过分期乐而成为第一，但当时的CEO没同意合并的方案，最后的故事就是我们融资不利，迅速败下阵来，而趣店后面绑上阿里而一飞冲天，很快就上市了，又是一次遗憾的错失，这也是离成功最近的一次了。
现在已经进入移动互联网时间，随着年龄越来越大，顾及越来越多，选择和折腾的成本太高了，只能选择大厂稳定了，所以见证了微信生态、短视频生态的此起彼伏，只能是望洋生叹了。
不过好在技术一直没有放下，内心还是一个技术爱好者，期望能蛰伏一段时间，沉淀一下，提升更多的非技术的认识，期待还有机会抓住一拔浪潮。
本人参与的swoole项目有幸被很多朋友使用，我也大力向周边的一些朋友推荐，随着swoole的版本迭代更新，已经足够稳定了，在阿里，腾讯，yy等各大公司都有着使用，也有很多游戏圈里的朋友也在使用，这些朋友经常会提到一个问题，每次代码更新还需要停止服务，然后重新启动，来达到更新代码，然而这种做法，是比较粗暴的。其实swoole里提供reload的特性，完全支持代码的热更新。
在介绍swoole的reload之前，先简要的讲讲web方式是如何改了文件就立即生效的：
几个概念：
1） sapi：可以简单的理解为php引擎对外的一个统一接口，使得php可以和外部程序进行交互
2） php的生命周期中关键四个调用：MINT -> RINT -> RSHUTDOWN -> MSHUTDOWN
3) fpm : fastcgi进程管理器
那么fpm方式的流程就是： fpm通过sapi接口与php进程交互，
在fpm启动的时候，
第一步： 会调用各扩展的MINT方法，进行一些数据初始化（长驻内存），
第二步： 每个请求过来，先会执行RINT对单个请求行一个初始化，
第三步： 执行php脚本，
第四步： 执行RSHUTDOWN方法，
第五步： 如果你要停止fpm了，才会执行MSHUTDOWN。
fpm对每个请求的处理都是一直在在重复执行 2~4步 。
在第三步中， php的脚本是动态执行的，由于每次都要执行一次php脚本，而每次php脚本都要有一个把php文件翻译成opcode的流程（比较耗时）, 于是就产生的opcache工具。
opcache: 直接把php翻译后的opcode代码树保存到共享内存中，以便直接使用，从而减少每次都把php翻译成opcode的开销。
opcache的问题：按照他的描述，修改了php文件，并不能立即被更新，
opcache的解决方案：有一个配置来设置隔多长时间检测文件是否更新了，从而有机会在第二步重新来reload相关的文件.
当然，你也可以直接reload fpm，从而达到php热更新的效果(opcache扩展可以在第四步把相关的opcode cache给清空)。
swoole的问题：
swoole是以cli运行的，然后长驻内存的。整个生命周期只有在启动的时间可以一次执行RINT过程， 之后所有的请求都在第三步以内完成。（这也是swoole更快的原因之一），这样的话，相关的php脚本如果被执行了一次，就永久性的长驻内存了，更新代码就没有效果了。
swoole的解决方案：内置方法 $serv->reload()
前提：swoole是一个三层架构： master->manager->worker， master和manager是启动之后，就长驻内存的，所以这里reload的是worker进程，（而我们的业务逻辑正好都在worker进程）。
简单原理： 调用$server->reload()的时候：
第一步： 向manager进程发送USR1信号，
第二步： manager捕获到USR1信号，会向worker进程发送 TERM信号。
第三步：worker进程捕获这个TERM信号，做把一个running的标识设置0
第四步：woker的事件循环发现running标识为0，处理完当前逻辑就会自杀（自杀前会回调onWorkerStop函数），
第五步：manager再拉起一个新的worker (拉起后会回调onWorkerStart函数）
从这个流程中我们会发现，onWorkerStart 和 onWorkerStop非常像 sapi里的 RINT, RSHUTDOWN.
所以到了这里，实现代码热更新的的方案就是：
把业务逻辑的脚本文件的载入放到onWorkerStart方法里，如果用了opcache，那么把一些opcache的清理逻辑放到onWorkerStop方法里。
示例：
function onWorkerStart($serv,$worker_id) {
include"hot_update_class.php";
$class=newHotUpdate();
}
function onWorkerStop($serv, $worker_id) {
opcache_reset(); //zend_opcache的opcache清理函数
}
这时如果我们修改了hot_update_class.php里的相关文件，再执行$serv->reload()，就可以实现热更新了。
ps: 所以，我们可以把onWorkerStart当成我的业务逻辑的入口。
（
如果你使用了autoloader, 那么你把autoloader的注册放到onWorkerStart里来。
如果你使用了框架，那么你可以把框架的入口文件放到onWorkerStart里来。
）
如果你开启了opcache，那么，你可以在onWorkerStop的时候，执行相关的opcache清理工作。
（zend_opcache，直接调用opcache_reset()方法即可）
示例：
function onWorkerStop($serv,$worker_id) {
opcache_reset(); //zend_opcache的
//apc, xcache, eacc等其他方式，请调用相关函数
}
最后希望这篇博客能给你带来一些帮助。（注：如果你的worker里挂了异步事件，比如把某个curl挂到swoole_event_add里，那么worker的reload会把这些都清理掉，可能导致一些逻辑错误，解决方案正在酝酿中）