关于 emqtt 推送问题,mqtt有时收不到消息疑难解答

 

一、客户端 连接冲突会发现以下报错 (开启 debug日志:把配置文件 的log.console.level 改为= debug)

11:20:55.849 [info] Session(060010100000868936): resumed by <0.21232.18>^M^M
11:20:55.849 [warning] Session(060010100000868936): <0.21232.18> kickout <0.31200.17>^M^M
11:20:55.849 [warning] Client(27.187.80.148:9093): clientid '060010100000868936' conflict with <0.21232.18>^M^M…

        

mysql使用utf8mb4经验吐血总结

ACMUG征集原创技术文章。详情请添加 A_CMUG或者扫描文末二维码关注我们的微信公众号。有奖征稿,请发送稿件至:acmug@acmug.com。
3306现金有奖征稿说明: 知识无价,劳动有偿,ACMUG特约撰稿人有奖回报计划(修订版)

作者简介: 周晓

网络常用id seanlook 。以前在TP-LINK做了2年Oracle DBA,后来专职做mysql了。平时在工作中遇到的些问题和处理经验,有空会写写放在自己的网站上 http://seanlook.com …

关于 MySQL UTF8 编码下生僻字符插入失败/假死问题的分析

1、问题:mysql 遇到某些中文插入异常

最近有同学反馈了这样一个问题:

上述语句在脚本中 load 入库的时候会 hang 住,web 前端、命令行操作则要么抛出

Incorrect string value: '\xF0\xA1\x8B\xBE\xE5\xA2...' for column 'name',

要么存入MYSQL数据库的内容会被截断或者乱码,而换做其它的中文则一切正常。

嗯,看起来有点奇怪哈,按理说 utf8 编码是覆盖了所有中文的,不应该出现上述问题。

2、原因:此 utf8 非彼 utf8

那我们先来看看插入异常的中文和正常的中文有啥区别:

可以看到上面插入异常的文字占了 4 个字节,而我们插入正常的则只占了 3 个字节。但是 utf8 字符编码不就是可变长,支持 1-4 字节的么?会和这个有关?

嗯,看看官方文档就知道了:

10.1.10.6 The utf8mb4 Character

周末有空,我们来聊聊几块钱的PHP

PHP现在不进则退,要么大家齐心协力把它带到新时代,要么一起跟着萎缩的市场从巅峰跌落

PHP以前是作为胶水语言成功的,它从数据库抓取数据,然后渲染成HTML进行输出。但由于前后端分离的大规模兴起,PHP的市场开始被压缩。因为前端已经大量JS化了,SPA化了,不需要PHP做胶水了,最狠的是JS连客户端、服务器端都能写了,它才是胶水,不,是万金油。国内目前感受不明显,只是因为前端太贵、好前端又太少,导致很多企业没转过去、以及某信催生了H5的一大片市场。

更不用说mobile first大潮下,很多产品只有APP没有Web了(Web是APP下载的静态页面),这又是另一大块丢掉的市场。

这样PHP基本就只能从胶水层,退守API层了。

PHP以前做API的优势是不明显的,一个是性能不好(至少没现在好)、一个是缺乏对并发、实时通信(比如Websocket)的支持。为什么我觉得鸟哥主导的PHP7方向非常正确、为什么我推荐韩天峰的Swoole?因为这两个东西解决了最明显的问题,大大提高了PHP作为服务端的竞争力。

那么,作为PHP开发者,如何应对?我个人觉得比较清晰的路线有三条。

最明显的,把JS精通了,吃掉专业前端的市场(反正大部分专业前端也不那么专业🙃),把写HTML的活抢回来。这是表现层,你依然要面对客户端对页面端市场的蚕食。当然我是希望RN和Weex能再成功一些,尤其是Weex采用Vue语法,这样你投资学习Vue就等于就全客户端了。但目前这块依然是遍地坑的状态,要么等、要么填。

第二个路线,学学Java之类的,把PHP和其他语言产品混用,往架构层走。ELK是Java的、Hadoop是Java的、一堆大公司开源的好东西全TM是Java的。(FB倒是开源了PHP的phabricator,code hosting、review、wiki、task&bug方面的一站式平台,也非常好用,但在CI部分功能还是实验状态。推荐PHP团队去用用。)

往架构层走是不是一定要学Java呢?其实也未必,靠Docker和微服务也可以。但Docker是Go写的,大部分微服务框架要么是Go要么是Java。倒是韩天峰用Swoole做了一个纯PHP的微服务方案,会在第三届PHP大会上分享,这个就等学习完再评价。

但整体来讲,PHP如果从页面胶水,进化到服务胶水,会开辟一大片市场;同时也为各位PHPer从Form builder到架构师铺平道路。

第三个路线,就是学C进系统层。这个倒不是特别难,但除非你做云,不然把系统弄得门清只会让你转行成DevOPS。真正有意思的地方是PHP和其他服务和系统接口的地方。比如Apache扩展、比如Nginx扩展、比如PHP扩展、比如PHP本身。用C语言封装基础能力,然后把它提供给PHP,可以在性能和易用性两方面获得很好的平衡,同时推动PHP语言的发展。这方面例子很多,Yaf、Yar、Swoole都是好示范。

仔细想想,如果架构层是在协议上和其他语言混用;系统层则是在代码和链接库层次上和其他语言混用。这是PHP过去成功的胶水战略在新时代的延伸。毕竟,靠一门语言打天下的时代已经过去了。啊不,JS或许还有希望🙈 。

我个人是很喜欢PHP简单直接的实用主义风格的,也希望PHP能一直流行下去。

但坦率的讲,我认为PHP现在处于一个不进则退的位置(去看TIOBE的语言排行就清楚了,应该还有三到五年的机会期),要么大家齐心协力把它带到新时代(比如PHP7、比如Swoole、比如Laravel、比如PHP栈的持续集成解决方案、比如PHP栈的微服务解决方案、比如PHP的机器学习库、比如PHP的Tensorflow封装),要么一起跟着萎缩的市场从巅峰滑落,就像Delphi一样。哦,抱歉,可能你们没听说过Delphi。[摊手]

 


 

顺便回答几个问题:

Q:你说的都是对的么?

A:不一定是对的,只是我现在以为对。注意这只是一个产品经理对PHP市场的观察 😂

Q:这个对PHP的看法是不是过于悲观了?

A:是的,这是比较坏的一种可能。但我们要考虑历史的进程。互联网时代已经过去、后移动互联网时代已经来临。只有拥抱时代的语言能活得好。运气好的语言可以撞大运,运气不好的语言只能主动去拥抱。我不希望PHP的未来要靠运气,我希望我们这些PHP开发者主动去能推动它,去做一些基础但有价值的事情,而不是等着别人来做(最后别人做了,用其他的语言),毕竟我们是最了解市场和需求的人,是过去从PHP上获益最多的人,也是有望从PHP的光明未来中获益最多的人。

Q:是不是PHP就不能学了?现在的PHP开发者就找不到工作了?

A:我对现状还是很乐观的,PHP依然是学习门槛最低、离钱最近的、现在还在供需顶部的「最好的语言」,不放心的可以关注白熊趣闻录里边的每周薪资播报,那个是实时数据。我个人觉得PHP的高需求时代应该还有三到五年(国内可能更久)。我的建议不是不学PHP,而是不要光学PHP。

Q:这些东西太多了,学习成本太高,我光学PHP找不到工作么?

A:可以的,但你至少还要会复制粘贴HTML、CSS和JQuery吧,不然怎么建(做)站(外包)。即使是在胶水时代,我认识的那些只会PHP的人后来都,对不起,我不认识光会PHP的人,他们至少会PS。

Q:为什么你要在文章里边给白熊趣闻录和第三届PHP大会做广告?

A:因为我觉得这两件事儿挺有意思的。而且公司的产品和朋友的大会做好了,对我有好处,对大家也没坏处,就顺手推荐给大家了。所有付费的商业广告,我都会单独标明。但我一般都懒得接。

题图来自:goeshand@zcool

在 PHP 中使用 Promise + co/yield 协程

摘要: 我们知道 JavaScript 自从有了 Generator 之后,就有了各种基于 Generator 封装的协程。其中 hprose 中封装的 Promise 和协程库实现了跟 ES2016 的 async/await 一样的功能,并且更加灵活。我们还知道 PHP 自从 5.5 之后,也引入了 Generator,同样也有了各种基于它封装的 PHP 协程库,hprose 同样也为 PHP 提供的跟 JavaScript 版本类似的 Promise 和协程库。下面我们就来看一下它跟 swoole 结合的效果。

    

PHP 知识补全 —— 生成器 (generator)和协程的实现

先说一些废话

PHP 5.5 以来,新的诸多特性又一次令 PHP 焕发新的光彩,虽然在本文写的时候已是 PHP 7 alpha 2 发布后的一段时间,但此时国内依旧是 php 5.3 的天下。不过我认为新的特性迟早会因为旧的版本的逐渐消失而变得越发重要,尤其是 PHP 7 的正式版出来后,因此本文的目的就是为了在这之前,帮助一些 PHPer 了解一些他们从没有了解的东西。所以打算将以本篇作为博客中 PHP 知识补全 系列文章的开篇。…