Dev

报错原因我们直接用supervisor启动gatewayworker 会发现都报错，无法启动这是因为 supervisor 无法管理后台程序，只能管理前台https://wenda.workerman.net/question/2671 解决办法修改start.php在Worker::runAll();之前增加代码 1Worker::$daemonize = false;

https://blog.csdn.net/hoooooly/article/details/82593558配置文件 1opcache.blacklist_filename=/usr/local/php/etc/opcache-blacklist.txt opcache-blacklist.txt的内容为 1/home/wwwroot/website/test.appname.com/*

mysql常用的锁有for update 和 for update in share mode两种 锁的区别 for update 我认为是悲观锁，其他事务读会被阻塞等待，写被禁止，且不准多次加锁 for update in share mode 读取不等待，写入会被禁止，可被多次加锁 in share mode的问题如果两个事务对同一行数据加锁很容易导致，两个事务都更新失败 使用场景基于以上特点介绍，in share mode可以用于两个表关联时，保护主表数据不被修改，for update更适合保护单表单行数据的正确性，适合投票、提现等场景 测试验证以下代码验证for update的作用表maxcount中marks初始为8，每次减1，当他大于0时，将当时数据保存，类似于抽奖中控制最大奖品数的问题tp中lock(true)会默认使用for update锁，我们每次测试修改代码即可 并发配置使用ab发400并发 1ab -n 400 -c 400 http://127.0.0.1/ 测试代码1234567891011121314151617$marks = -1;Db::tra...

原文地址http://www.thinkphp.cn/topic/42766.html 注意端口 数据库等 pgsql中没有table_msg这个函数需要自己到库中定义，如下所示pgsql postgresql中没有 这个 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117CREATE OR REPLACE FUNCTION pgsql_type(a_type varchar) RETURNS varchar AS $BODY$ DECLARE v_type varchar; BEGIN IF a_type='...

从我2015年真正全职做程序开始已经3年，现在开始感觉前所未有的焦虑以前也会焦虑，那时候其实是啥也做不好，现在感觉自己被程序 外包困住，我感觉外包累了 今年已经有至少3个项目和客户关系出了问题，并不是做不好，而是人疲惫后，客户惹我不开心，我就想喷他当然我也做了相应的改变，我开始找团队一起做，但是这个路并不平坦，一样有很多问题 一起做的人对广告行业了解不足，我还是很难彻底脱离。 最近也看了一些以前朋友做的事情，有朋友做支付宝服务商、做小程序系统，感觉还是赚了不少的我现在也希望能做一套系统，系统开发需要考虑用户，要考虑销售方式，所以还总是要搞关系，脱离不了这么麻烦的事 面向企业面向商户面向个人

服务器腾讯更好 支持按量阶梯付费，带来的好处是可以随时升降服务器配置，这对像我一样的广告开发实在太重要了 微信内网通信，速度快的飞起，如果主要业务是围绕微信更是不二之选 serverless阿里云更好 支持php-fpm 支持http触发，除了自定义域名，已经具备了实际使用的价值 vpc腾讯更好 支持将自己的服务器作为vpc的网关

2018年08月，IOS微信发新版，带来了悬浮球等便捷功能，但是也带来了一个IOS底部白色导航栏的问题，这个微信自作聪明的功能，被众多广告主所厌恶，解决的难题摆在了程序面前 问题描述常规来讲，我们需要登录的页面，都是检测登录后，如果未登录，就用location.href进行跳转，引导用户授权登录，但是新版IOS微信这样做的时候，微信会在底部自动填加一个白色的导航栏，不受程序控制，进一步减少了屏幕显示空间 解决办法经过大量实验，我们发现如果是使用header告知浏览器进行30X跳转，这时微信不会增加这个白边所以我们目前分享和二维码上的链接都是后端接口地址，根据登录状态给出合理的跳转地址用户端无感 方法实例如下 1234567891011121314151617public function index(){ $user = is_userlogin($this->appid); if (!empty($user)) { return redirect($this->html); } else ...

客户很多时候难以正确理解概率的意义，或者难以给出概率，此时可大致上把奖品数量作为权重进行抽奖权重作为概率抽奖时，可以用循环把每个奖品放进数组，权重多大就有多少个值，然后用array_rand获取数组的key，再获得奖品但是客户可能要求不同时段概率不同，所以我们可以事先将所有概率和时段的关系写好，然后抽奖时进行判断，获取相应的权重数组，之后再执行上述权重作为概率抽奖 权重抽奖实例123456789101112131415161718192021222324252627282930313233343536373839404142$current = date('Y-m-d H:i:s');// $current = '2018-08-30 18:30:00';$keys = array_keys($this->weight);$period = [];$nowkey = '';foreach ($keys as $k => $v){ // 当前约束 $nowkey = $v; //...

作为广告行业中的一环，我们每年要完成大量的抽奖活动抽奖活动看似简单，实际上在高并发，大流量情况下不把奖品发错，又能百分百按客户要求还是有一定难度主要有以下难点 客户奖品规则不定，有时候所有奖品都是按概率给出，有时候所获奖品又和以前中奖情况关联（例如：客户可能要求，中过杯子的人不能再中优惠券） 客户对数量要求不定，可能有的客户希望按周去控制总数，有的要按天控制，有的要按工作日和周末去控制 客户可能随时修改已经规定好的数量 为满足所有客户要求，目前解决方案如下 提前制定若干奖池，根据不同的情况去从不同的奖池里获取 根据特殊规则，从奖池删除特定奖品，然后再抽奖 为精细化、高度定制奖品数规则，可先和客户协商时段，比如2018-09-11 09:00-10:00发多少数量的奖品，只要在这个时段的奖品都应该在数据库计数+1，然后和给定的最大值比较，以确保奖品不要超发 客户需要修改奖品数量时，只要修改最值即可，但是时段尽可能不要修改

我们每年要做大量的H5广告 H5游戏等，很多时候需要用到微信登录微信登录主要面对几个大问题 H5项目登录获取的信息不一致，有时需要头像，有时仅需要openid，两个级别的微信授权，前者体验较差，应该尽量避免 登录所用的公众号不一样，有时客户没有服务号，可以使用我们提供的，有时又一定客户指定的服务号 使用客户服务号，很多时候我们无法调整用户服务号配置，这可能会导致客户已有程序出错 放在客户域名下，因跨域导致ajax无法使用，不易检测登录 为解决这些问题，给出以下解决方案 统一微信授权接口，授权时传入当前页面地址，授权流程结束后，跳转到原H5地址 在前端js跳转时就确定好使用snsapi_userinfo级别还是snsapi_base级别的授权，或具体的活动逻辑处进行检测 注册微信开放平台(open.weixin.qq.com)，使用微信第三方平台接口进行授权，不需要修改客户服务号授权回调域名，以此保证不会影响客户公众号已有程序 可在前端页面使用jsonp向活动接口检测登录状态以下给出前端jsonp检测登录代码 12345678910111213141516171819202...