性能之王,MySQL 8.0 GA版本发布!

MySQL 5.7可以被称为近10年最为经典的版本,正如同96年NBA的芝加哥公牛队,2011年的巴塞罗那队。一代王朝建立,远远甩开原本的竞争对手们。Percona、MariaDB、PostgreSQL们足够努力,只是好学生永远无法追赶闪着光芒的天才。回望过去的3年,现在拿着望远镜,MySQL也已找不到对手。

芝加哥公牛队三冠王,巴萨十年王朝告诉我们,王朝一旦建立,将会势不可挡。今天MySQL 8.0版本GA,至此MySQL这艘之前的巡洋舰,摇身变为一搜巨型航母,未来必将开拓更多的领域,影响更多行业对于开源数据库的应用。

MySQL 5.7版本解决了很多企业级数据库应用的痛点,诸多企业从老版本(例如5.5、5.6)升级到了5.7。甚至在传统领域,MySQL也已经撬动和影响了很多行业。5.7.17发布的MySQL Group Replication必将在未来3年内成为金融行业数据库解决方案的事实标准。

MySQL 8.0是新一代的性能之王。200W QPS不再是瓶颈,这狠狠打脸了Redis、MongoDB、MariaDB、PostgreSQL、TiDB这样的竞争对手。当对手们还在对性能遮遮掩掩时,MySQL已然无可挑剔。

云时代,MySQL 8.0带来了包括但不限于以下的诸多新特性:

· InnoDB各模块重构,性能可有30% ~ 100%的大幅提升(具体见:MySQL 8.0 200W QPS!!!InnoDB大重构 #M1005#);

· 更好的从机多线程复制机制(writeset-based MTS)机制,至此彻底解决困扰MySQL多年的从机复制延迟问题(具体见:滚蛋吧,MySQL主从复制延迟 #M1002#);

· 支持基于角色的用户管理,更好地对用户进行更细粒度的管理;

· 基于InnoDB的New Data Diction(新元数据字典),Atomic

又不一样的 Symfony —— SF4 展望

作为一个 Symfony 框架的老用户,symfony(注意那个年代 s 还是小写的) 诞生于 PHP <5.2 时代,跟 PHP 5.3 时代的 Symfony2 相比简直天壤之别。而最近 Symfony3 的发布让我发现,似乎改动也不是很大,心想该不是 Symfony 也学 Chrome 那样加版本号了吧?这几天 Symfony 开发组老大又开始说 Symfony4 要发布的事情,但内容倒不至于让我太失望,的确变化也不小。下面就来说说老大哥提到了 SF4 到底有哪些变化。…

    

你必须知道的 17 个 Composer 最佳实践(已更新至 22 个)

尽管大多数 PHP 开发人员都知道如何使用 Composer,但并不是所有的人都在有效的或以最好的方式来使用它。 所以我决定总结一些在我日常工作流程很重要的东西。

大多数技巧的哲学是 “稳,不冒险”,这意味着如果有更多的方法来处理某些事情,我会使用最有把握不容易出错的方法。

Ellison 翻译于 2个月前

 查看其他 1 个版本

    

不依赖框架写出现代化 PHP 代码

我为你们准备了一个富有挑战性的事情。接下来你们将以  框架的方式开启一个项目之旅。

首先声明, 这篇并非又臭又长的反框架裹脚布文章。也不是推销 非原创 思想 。毕竟, 我们还将在接下来的开发之旅中使用其他框架开发者编写的辅助包。我对这个领域的创新也是持无可非议的态度。

这无关他人,而是关乎己身。作为一名开发者,它将有机会让你成长。

也许无框架开发令你受益匪浅的地方就是,可以从底层运作的层面中汲取丰富的知识。抛却依赖神奇的,帮你处理无法调试和无法真正理解的东西的框架,你将清楚的看到这一切是如何发生的。

很有可能下一份工作中,你并不能随心所以地选择框架开拓新项目。现实就是,在很多高价值,关键业务的 PHP 工作中均使用现有应用。 并且该应用程序是否构建在当前令人舒爽的 LaravelSymfony 等流行框架中,亦或是陈旧过时的 CodeIgniter 或者 FuelPHP 中,更有甚者它可能广泛出现在令人沮丧的  “面向包含体系结构” 的传统的 PHP 应用 之中,所以框架开发会在将来你所面临的任何 PHP 项目中助你一臂之力。

上古时代, 因为 某些系统 不得不解释分发 HTTP 请求,发送 HTTP

    

58到家MySQL军规升级版

一、基础规范

  • 表存储引擎必须使用InnoDB

 

  • 表字符集默认使用utf8,必要时候使用utf8mb4

解读:

1)通用,无乱码风险,汉字3字节,英文1字节

2utf8mb4utf8的超集,有存储4字节例如表情符号时,使用它

 

  • 禁止使用存储过程,视图,触发器,Event

解读:

1)对数据库性能影响较大,互联网业务,能让站点层和服务层干的事情,不要交到数据库层

2)调试,排错,迁移都比较困难,扩展性较差

 

  • 禁止在数据库中存储大文件,例如照片,可以将大文件存储在对象存储系统,数据库中存储路径
  • 禁止在线上环境做数据库压力测试
  • 测试,开发,线上数据库环境必须隔离

 

二、命名规范

  • 库名,表名,列名必须用小写,采用下划线分隔

解读:abc

[原创首发]关于如何正确使用PHP框架及如何选择框架之我见.

用PHP 开发程序这么多年了,今天想和大家谈谈如何正确使用PHP框架.

即关于PHP开发什么时候用框架,用不用框架,用什么框架,不同项目是否用不同框架,是否要学习多个框架,付出多少学习成本等问题.

先说一下,我用过的框架有:Swoole, Laravel, phalcon ,symfony, codeigniter, thinkphp.

这几个框架都有什么特点? 有没有做什么项目都通吃的框架?

先说一下swoole,swoole是用C写的PHP扩展,性能很高,通常用于写后台服务和网络通信程序.,但是对于一般的普通web程序它不太适合.并且学习难度大.当然如果你追求性能,写后台服务和接口还是适合的.

再说一下 Phalcon这个框架,同样的C写的全栈框架,以php扩展方式发布,性能可以说是最好的.但是因为一是英文的文档,要求你英文比较好.phalcon在国内用的人比较少,所以中文文档不多.phalcon写web程序和接口都是很好的.但不适合写后台服务.还有一点是这个框架虽然好,但是因为是C写的,如果有一些bug,就要等官方修复,或需要你懂C语言自己来修复.还有一点扩展性不好,如果你想加新功能,比如mongodb数据库支持,它是支持的,但是需要是老的php mongo扩展,用新的php mongodb扩展的话,就需要写php代码来实现,这就降低了性能.所以说这框架很好,但还是有一些不便.

其次是Laravel这个框架,最近可是风头正旺,号称最好的框架,以优雅著称.也像phalcon一样,用到了最新的一些概念:如composer,依赖注入,服务定位等.国内用的人也不少,中文文档及资料也比较多.但是我想说的是性能是这个框架的硬伤,新安装的laravel 5.1 框架 输出一个hello world 每秒rps 才达到几十, 而最 新发布的laravel 5.5 及性能居然还不及laravel 5.1版.究其原因是因为这个框架一启动就加载了一百多个文件,这就是性能很低的原因(IO开销很贵的!). 这个框架再好,但是性能太低,就需要拿硬件来支撑.除非你是土壕,否则还是不建议用Laravel 这个框架.

再说一下 …

            

[总结]FFMPEG视音频编解码零基础学习方法

在CSDN上的这一段日子,接触到了很多同行业的人,尤其是使用FFMPEG进行视音频编解码的人,有的已经是有多年经验的“大神”,有的是刚开始学习的初学者。在和大家探讨的过程中,我忽然发现了一个问题:在“大神”和初学者之间好像有一个不可逾越的鸿沟。“大神”们水平高超,探讨着深奥的问题;而初学者们还停留在入门阶段。究竟是什么原因造成的这种“两极分化”呢?最后,我发现了问题的关键:FFMPEG难度比较大,却没有一个循序渐进,由简单到复杂的教程。现在网上的有关FFMPEG的教程多半难度比较大,不太适合刚接触FFMPEG的人学习;而且很多的例子程序编译通不过,极大地打消了学习的积极性。我自己在刚开始学习FFMPEG的时候也遇到了很大的困难。为了帮助更多的人快速成为“大神”,我想总结一个学习FFMPEG的方法,方便大家循序渐进的学习FFMPEG。

PS:有不少人不清楚“FFmpeg”应该怎么读。它读作“ef ef em peg”

0. 背景知识

本章主要介绍一下FFMPEG都用在了哪里(在这里仅列几个我所知的,其实远比这个多)。说白了就是为了说明:FFMPEG是非常重要的。

使用FFMPEG作为内核视频播放器:

Mplayer,ffplay,射手播放器,暴风影音,KMPlayer,QQ影音...

使用FFMPEG作为内核的Directshow Filter:

ffdshow,lav filters...

使用FFMPEG作为内核的转码工具:

ffmpeg,格式工厂...

事实上,FFMPEG的视音频编解码功能确实太强大了,几乎囊括了现存所有的视音频编码标准,因此只要做视音频开发,几乎离不开它。

对于完全没有视音频技术背景的人来说,在学习FFmpeg之前最好先了解一下几种最基本的视音频数据的格式,可以参考下面的文章:

[总结]视音频编解码技术零基础学习方法

视音频数据处理入门:RGB、YUV像素数据处理

视音频数据处理入门:PCM音频采样数据处理

视音频数据处理入门:H.264视频码流解析

视音频数据处理入门:AAC音频码流解析

视音频数据处理入门:FLV封装格式解析

视音频数据处理入门:UDP-RTP协议解析

1. ffmpeg程序的使用(ffmpeg.exe,ffplay.exe,ffprobe.exe)

 

【视频资源】

本文中第1,2章是FFmpeg编程最基础的内容。这部分的内容我在给大二同学代课的时候录制成了视频,有时间的话可以看一下《基于 FFmpeg + SDL 的视频播放器的制作》课程的视频

本章主要介绍一下ffmpeg工程包含的三个exe的使用方法。

ffmpeg的官方网站是:http://ffmpeg.org/

    

关于FFmpeg工具的使用总结

FFmpeg官网:http://ffmpeg.org/
安装ffmpeg:
主要参数:
-i 设定输入流
-f 设定输出格式
-ss 开始时间
视频参数:
-b 设定视频流量,默认为200Kbit/s
-r 设定帧速率,默认为25
-s 设定画面的宽与高
-aspect 设定画面的比例
-vn 不处理视频
-vcodec 设定视频编解码器,未设定时则使用与输入流相同的编解码器
音频参数:
-ar 设定采样率
-ac 设定声音的Channel数
-acodec 设定声音编解码器,未设定时则使用与输入流相同的编解码器
-an 不处理音频
拓展:
-strict -2 之前是实验参数表示 aac音频编码 如果不使用aac音频编码使用使其的编码好像还需要导入第三方的音频编码库 比较麻烦
    

使用FFMPEG生成HLS

使用FFmpeg生成HLS

 

HLS也就是HTTP Live Streaming,是苹果出的一个基于HTTP的流媒体通信协议。字面意思有个live,也就是直播相关的。其实HLS可以分为点播以及直播两种。后面具体说两者在处理上有什么区别。目前HLS在RFC上还只是草案,并且一直不断更新,发现ffmpeg对于HLS的实现,不同版本的实现对应rfc版本也不一样,最新版本的,对应的HLS RFC草案规范也比较新(追新并不一定好,有些设备对于新版本的规范支持还不是很完整,可能会有播放失败的问题,所以如果需要正常使用,选择一个稳定的版本即可)。rfc的草案现在到了16版本。由于项目比较敢,这规范其实我看的不多。

HLS对于音视频是有编码要求的,HLS要求视频必须是H264协议,H264是目前最流行也是最成熟的视频编解码方案了。而在音频上,则要求为MP3, HE-AAC或AC-3这三种格式。在转换成HLS流后,会生成多个的TS文件。如果是点播的话,则是对视频文件进行TS的切片处理,一般情况下,每个TS文件的播放时间为10秒。但这并不是固定的,切片的多少,这是会影响直播的延迟情况。这个后面会稍微做一些说明。

HLS会生成一个m3u8的播放文件。这个播放文件可以通过VLC等一些播放器直接播放。现在大部分手机也支持HLS了,所以手机也是可以进行对HLS的直播或点播进行观看。但是目前的桌面端浏览器尚未完全支持HTML5的HLS播放,大部分直播还是依赖flash player进行封装直播(据说国内的很多视频站有自己的播放技术)。这边主要讨论的并非是桌面端,主要还是移动端的支持。

现在简单说一下m3u8文件。以下是由ffmpeg生成的一个直播的m3u8文件: