音乐 - 小青呱

发布于
来源：https://www.bilibili.com/video/BV1wZ4y1M7bM

评论

发表评论

此博客中的热门博文

thinkphp-queue 笔记

发布于
前言 当前笔记中的内容针对的是 thinkphp-queue 的 v2.0 版本 传统的程序执行流程一般是 即时|同步|串行的，在某些场景下，会存在并发低，吞吐量低，响应时间长等问题。在大型系统中，一般会引入消息队列的组件，将流程中部分任务抽离出来放入消息队列，并由专门的消费者作针对性的处理，从而降低系统耦合度，提高系统性能和可用性。 一般来说，可以抽离的任务具有以下的特点： 允许延后|异步|并行处理   （相对于传统的   即时|同步|串行   的执行方式） 允许延后 ： 抢购活动时，先快速缓冲有限的参与人数到消息队列，后续再排队处理实际的抢购业务； 允许异步 ： 业务处理过程中的邮件，短信等通知 允许并行 ： 用户支付成功之后，邮件通知，微信通知，短信通知可以由多个不同的消费者并行执行，通知到达的时间不要求先后顺序。 允许失败和重试 强一致性的业务放入核心流程处理 无一致性要求或最终一致即可的业务放入队列处理 thinkphp-queue   是thinkphp 官方提供的一个消息队列服务，它支持消息队列的一些基本特性： 消息的 发布 ， 获取 ， 执行 ， 删除 ， 重发 ， 失败处理 ， 延迟执行 ， 超时控制 等 队列的 多队列 ，   内存限制   ， 启动 ， 停止 ， 守护 等 消息队列可 降级为同步执行 thinkphp-queue 内置了   Redis ， Database ， Topthink   ， Sync 这四种驱动。本文主要介绍 thinkphp-queue 结合其内置的 redis 驱动的使用方式和基本原理。 注1：如无特殊说明，下文中的 ‘消息’ 和 ‘任务’两个词指代的是同一个概念，即队列中的一个成员。该成员对消息队列而言是其内部保存的消息； 对业务应用而言是一个待执行的任务。请根据语境区分。 注2：本文编写时(2019-01-30)使用的 thinkphp-queue 的版本号是 v2.0 。如有变更，请以官方最新版为准。 一 代码示例 先通过一段代码，了解一下 thinkphp-queue 的基本使用流程。 目标： 在业务控制器中推送...
阅读全文

Cloudflare免费版设置说明

发布于
一：域名接入 Cloudflare 这一步其实能说的不是很多，因为我已经添加过域名了，也不好意思随便加别人的域名来测试，所以就只跟大家简单的说说吧。 注册账号之后先把自己想接入 CDN 的域名添加好，然后应该会有 Cloudflare 的提示，告诉你要把域名的 NS 记录改成 Cloudflare 的： NS 记录的修改需要到你的域名注册商那边改，这个根据各商家面板的不同可能设置上稍有差异，请自行查找。域名注册商那边改好之后，应该在 Cloudflare 这边刷新一下就能看到已经帮你添加好的各种记录了，默认支持 CDN 的也已经帮你开启了 CDN 功能，如果没有，就自己按照原来的记录重新添加一份，然后最重要的把 A AAAA 记录这种开启 CDN 功能。 此处提一下，不知道大家知不知道 NS 记录的用途？当我们改成 Cloudflare 的 NS 之后，其实以后我们就不需要到域名注册商那边去添加各种 A AAAA 记录了，全部都在 Cloudflare 这边完成，因为已经被接管了。 另外请注意，域名接入的说明是针对免费版 Cloudflare 来说的，用的合作伙伴那种接入方法的我这里就不说了，一般人家面板上会告诉你怎么操作（其实也就是绑定下域名到域名注册商那边改一下 A AAAA 记录之类的）。 二：后台概览页面介绍 在正式给大家说明各类设置项之前，我们先来看看 Cloudflare 的概览界面： 上面那一排排的按钮就是各种设置项了，第一项就是概览。 概览页面可以看到一些常规的 CDN 缓存数据大小还有命中率什么的，页面左边是一些功能的快捷开关，方便我们平时有需要时随时开随时关，翻译已给大家奉上。 概览按钮后面接的是 Analytics 功能，主要是用来展示一些详细的统计数据之类的，因为基本不含设置项，而且与本文标题不太相关，所以就不多介绍直接跳过了。 三：DNS 设置 防止有些人还找不到我说的是什么设置项，我就直接上图说了： 标的框框这里是让你快速添加各种主机记录用的，后面的图标亮着代表开启 CDN 功能，不想开就手动点一下关闭就是了。 关于 DNS 的设置部分，因为主要就是各种记录的添加，所以没什么好说的，只需要注意给你要开启 CDN 的域名添加正确的记录就是了，记录的设置和在原来域...
阅读全文

买二手车选择哪个网络平台好

发布于
从购车需要专业技能程度来排行（从高到低），（汽车拍卖平台）车置宝=车速拍=优信拍>（二手车信息平台）58同城=二手车之家=赶集=咸鱼>（超级中间商）瓜子二手车=人人车=优信全国购 像汽车拍卖平台基本上都算是车商的批发平台 上面的车鱼龙混杂，什么车都有 大部分都是市场里买不出积压很久的库存车辆 只有很少一部分是个人的车源 也有很多事故车在上面流通 至于上面的评估报告 简单看一下就好 准确率一般般 评估师评估的很一般 而且很难实地看车 这种平台唯一的优势就是价格比其他平台低一些 记住是低一些！不是低于市场价！ 上面有很多车商在和你共同竞价 价格一般都会控制在车商收购价左右 假如一辆市场零售价10w的车，市场收车价8.5w 在拍卖平台上成交价可能在8.2w-9.2w这个区间 至于这个价格怎么把控 就要看这辆车的车况 车况不错，你出9.2w拿下来都划算 车况不好，8w拿回家都亏 还有一点就是 拍卖平台上的车源流动性很大 基本上每天都有成百上千辆车不停的流通 要想挑到符合自己需求的车，需要每天都上去望一眼 如果身边有懂二手车的朋友可以去上面捡捡便宜车 要是没有！请忘记我说的这个平台 买到有问题的车 平台可不会给你有任何赔偿 专业难度：?????（极高） 购车风险：?????（极高） 车辆车况：??（低） 车辆价格：????（低） 购车时长：??（长） 推荐指数：??（不太推荐） 注：需要专业知识，二手车评估，二手车估价，二手车购车流程 接下来我们说一说二手车信息平台58同城、二手车之家、赶集、咸鱼等 这种平台类属于我们小区门口的公示栏 他提供一个广告位 车商陆陆续续的在上面发自己的车源小广告 平台赚取的是车商发布车源的推广费用 上面车源质量会比拍卖平台上的车源好一些 至少你按照正常市场价购买的车辆 碰到事故车的可能性会小很多 车源也很丰富 不用每天都上去看有没有喜欢的车， 发布车源的车商基本上都有实体店 可以带评估师上门看实车车况 过户手续可以让车商解决 相对拍卖平台风险会小很多 购车时间也很短 钱到位了直接开走约过户就可以了 出问题闹事也方便（手动狗头） 价格基本都可以砍 按照正常行情价砍车商也不会介意什么的 现在车商基本上有点利润空间就卖 但是你要拿个传奇屠龙刀去杀价 10w零售价的车对半砍5w 车商也会默默的帮你把杯中的茶加满 面带微笑的告诉你出门左转有家医...
阅读全文

打造一个可国内访问的Blogger（Blogspot）方法

发布于
  Blog‍‌‍‌​‌‌‌‌​‌​‍‌​‍‌‍‍​‌‌‍‌​‌‍​‍‌​​‍‌‌‌​‌‍‌‌​‍‍‍​‍‍‌​​‍‌‍‌​‍‌‍‍​‌‌‍‌​‌‍​‍‌​​‍​‍‍‍​‌‍‍‌ger,一个干爽、免费的博客发布平台，作为主流的发布，提供免费的托管，免去了Typecho&Wordpress高昂的服务器费用，避免了Hexo&Jekyll静态博客无后台的缺陷，与CSDN、简书相比，可以绑定域名，界面干净，无广告【当然可以自己放自己的广告】。 实际上，当今写博客的软件数不胜数，主要分为一下三类： 服务器部署：典型代表：Wordpress\Typecho 无服务器托管：典型代表：Hexo\Jekyll\Gidea\Hugo\Hola等等 集成型网站：Blogger、简书、CSDN、cnblog、wodemo等等 上面所有软件，优缺点都有，具体看个人选择 当然，个人认为Typecho适合做个人博客，Hexo可以作为要求不高的人。集成性网站最主要的是只要安安心心写文章，不用管后端乱七八糟的代码。当然，最有问题的是大多数都不支持绑定域名，而且经常往网站上塞广告，自定义范围也不够。 接下来，我们扯扯集成博客中的一股清流：Blogger Blogger.com是由Pyra Labs公司创立，是目前全球用户数量最多的个人网志服务提供商。Pyra Labs和Blogger.com均被Google公司收购，成为其旗下的一项服务内容。 Blogger提供免费主机Blogspot.com存放博客，用户不必写任何代码或者安装服务器软件或脚本，通过所见即所得界面轻松地创建、发布、维护和修改自己的网志。 Blogger允许有经验的用户自行设计博客界面，其模板支持使用HTML和CSS进行编辑 实际上，由于Blogger托管于谷歌，写作域名  www.blogger.com  和托管域名  *.blogspot.com  均被MainLand所Ban。但是接下来来，我会讲讲如何打造一个能在国内大陆访问的Blogger 1. 注册Blogger 众所周知，请善用技术上网。 用谷歌账号登录 ( https://www.blogger.com ) ，没有？不是⑧不是吧不是扒，都0202年了，还不会去注册一个谷歌账号？ 进入控制台，新建一个博客： 绑...
阅读全文

CDN的选择讨论（甜糖、网心云、超点云、猕猴桃）

发布于
  作者网络是广西电信单线120m下行，35m上行，n拨环境，无公网ip，大内网环境。设备有一台nas，一台双路E5服务器。期间挂过多种cdn赚电费网费，总结一下经验分享给大家，给大家赚电费一点参考。 对于单线上行50m以下渣友我推荐甜糖，50m往上我推荐猕猴桃和超点云。 （1）甜糖： 优点： 1） CPU占用极低 ，一个j1900开20个容器没问题（就是内存不够），相对于后面3个CDN，多开的时候这是个非常大的优势。 2）docker快速部署，只要能运行docker就可以部署。 3） 内存仅需1g ，部署多个只需要无脑加内存就可以了。 4）无需考虑磁盘性能， 一个16g优盘便可轻松跑满30m上行 ，家里有闲置优盘，又不想购买ssd等跑量的渣友比较好的选择。 5）网络连接数非常小（只有两位数，其他cdn都是2000起步），对路由器负担很小。 6） 部署一天就能跑量 。 缺点： 1）由于缓存过小，上游业务不足，实际调度起伏较大，不容易带宽跑满，有时甚至一天都没有收益。 2）就算使用大容量ssd，也不会缓存大量数据装满ssd，对跑量帮助性价比较低，不如优盘划算。对于有闲置固态，机械硬盘的渣友不如别家cdn划算。 3）网络部署 不支持upnp，需要自行设置端口转发或DMZ 。 4）不支持多线汇聚，需要为甜糖设置专用线路。 评论：入门小水管cdn首选，基本只要是台设备都可以部署，基本不增加任何部署 成本 ，适合 想直接赚点电费的省心渣友： 1）玩客云/N1+闲置优盘部署首选，最快扳回来方案。 2）NAS空间不多， 不想另外添加硬盘，不占用小姐姐的空间，近乎白嫖。 （2）猕猴桃： 优点： 1） 支持多线汇聚 ，网络只需要设置好upnp即可（多线用户还需要设置端口分流）。 2）一台设备只需要开一个猕猴桃，会自动根据磁盘容量多个进程（350g/300g一个进程），榨干你的硬盘和带宽。 3）上游调度不错， 带宽利用率高 ，部署快（尤其是多进程）， 一天就能跑量 。 4）一个进程（350g/300g一个进程）就能跑满30m上行，适合有闲置机械硬盘的用户 。 5）安装方便， 全自动设置 ，官方设置的很好，部署基本不会遇到疑难杂症。 缺点： 1）没有app，只有微信小程序，功能比较简陋。 2）宣发太弱，知名度较低，官网主...
阅读全文

开源数据库中间件的对比、选取和搭建

发布于
Proxy式架构和客户端式架构的优劣     Proxy式架构 客户端式架构 优点 1， 集中式管理监控和升级维护方便 2， 解决连接数问题 1.     应用直连数据库性能高 2.     无需中间层集群，没有额外成本开销 劣势 1， 需要中间层集群，有硬件成本开销 2， 多一跳(hop)有一定性能损失 3，中间层做数据合并，需要做隔离机制 1.     客户端和应用耦合，管理监控和升级维护麻烦 2.     不解决连接数问题   选择困难症时期： 在选取中间件的时候 我们会考虑社区的活跃度 版本的更新情况，维护成本，而这些综合比较起来我们初步定了 DBProxy，kingshard，mycat，其中DBProxy采用c，kingshard采用golang，mycat采用java，而考虑C的维护成本，我们暂时放下了（此处没有歧视C的意思，只是想说C太高深了），而kingshard是由个人组织开发的，mycat由一个团队维护，对于使用哪一种，暂时没有完全定一来。 我们从另一个方面来考虑一下，其实使用中间件的时候，大部分是已经到了不得不分表分库的情况下了（这是根据本人从业的公司情况，不一定都如此），那么要分表，我们来考虑中间件使用的情况，假设我们要查id从1到100范围的值，而我们现在分了16张表，那么其实我们要做的是select 每一张表，把符合id在1到100的查出来，再把数据组合到一起，返回给你，那么这里其实你需要查16张表，表的数量越多，你其实查的很多，从这个角度来看，哪一种更有优势呢？似乎是采用golang的kingshard，大家都知道golang具有良好的并发性能，语言非常简洁，对于维护人员上手也是比较快的，综合考虑一下，我们选择了kingshard。 安装： kingshard的安装，比较简单，我这里也是作者那里过来，但是对于不是很熟悉go的，又想马上看到kingshard的惊人效果来说，切记不要浮躁。 1. 安装Go语言环境（Go版本1.6以上），具体步骤请Goog...
阅读全文

ELK实时分析之php的laravel项目日志

发布于
最近因公司项目增多，且环境也越来复杂，开发人员找我查看错误日志越来越频繁，心里便念想到ELK，心之所想，念之所达，快来get一项新技能吧 1、系统架构组成 laravel日志：日志源通过filebeat将日志写进redis中间件 logstsh：logstash通过input将redis数据拿来分析，通过其filter模块分析所需要的语句，然后输出到elasticsearch 3.elasticsearch 接收logstash发送过来的数据，并提供了一个分布式多用户能力的全文搜索引擎 Kibana是一个优秀的前端日志展示框架，它可以非常详细的将日志转化为各种图表，为用户提供强大的数据可视化支持。 二、各个服务的ip地址 laravel: 172.18.109.227 redis: 172.18.215.207 elasticsearch: 172.18.215.207 kibana: 172.18.215.207 复制代码 三、laravel日志服务器配置： 配置filebeat yum源文件 [elastic-5.x] name=Elastic repository for 5.x packages baseurl=https://artifacts.elastic.co/packages/5.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type =rpm-md 复制代码 安装filebeat yum install filebeat 复制代码 配置filebeat配置文件 ... #写入源 - input_type: log paths: - /var/www/html/*/storage/logs/laravel-2018-12-29.log ... #输出至redis output.redis: # Array of hosts to connect to. hosts: [ "172.18.215.207:6379" ] password: "***********" db: 0 timeout: 5...
阅读全文

一个轻量级通用的数据同步方案

发布于
在不同的数据库系统之间做数据同步是大数据领域里常见的需求。一个典型的场景是，业务系统因为需要事务和随机查询，一般会使用 MySQL 这种数据库；数据仓库使用 Hive；ETL 之后的结果再放到 MySQL、AWS Redshift 等系统给 BI 和报表工具使用。 首先梳理一下需求和目标： 实时性：非实时，离线同步，一般为 T+1，或最细到小时粒度 扩展性：需要支持多种异构数据源，如 MySQL, Hive, ElasticSearch 等 性能要求：因为是离线系统，对性能要求无严格要求，但最好尽可能快，并有可能调优 复杂度：复杂度低，依赖少，易使用，易运维 功能要求：要满足全量同步和增量数据同步 解决方案 数据同步并不是一个特殊的问题，简化一下其实就是两个操作：读和写。与之类似的是数据库备份和恢复，很多数据库系统都自带这种工具，比如 MySQL 的 mysqldump 和 mysqlimport ，MongoDB 的 mongodump 和 mongorestore 等。这些工具一般为了性能而使用特殊的编码格式，不会考虑通用性。但一个通用的数据同步系统，可以采用同样的思路来实现。 上图描述的就是本文的解决方案，即把读写拆分，通过 CSV 文件来过度。 扩展性 这种设计的核心是把数据同步抽象成导出（读）和导入（写）两个过程，完全解耦，因此具有很好的扩展性。每种数据源只需要实现读写两种操作即可。以常见的数据源为例，看看分别如何实现从 CSV 导入数据（导出到 CSV 很容易，使用任意编程语言都可实现）。 数据源 导入 CSV MySQL 使用 LOAD DATA LOCAL INFILE 批量加载，或读取文件运行 INSERT 语句 AWS Redshift 以 AWS S3 为中转，使用 COPY 命令批量加载 Hive 建表时指定 Serde 为 org.apache.hadoop.hive.serde2.OpenCSVSerde ，或者在导入前把 CSV 先转换成默认的 TEXTFILE 格式；然后使用 LOAD DATA [LOCAL] INPATH 批量加载。 ElasticSearch 读取文件，批量插入 FTP, AWS S...
阅读全文

kubernetes中部署mysql高可用集群

发布于
很多软件后端使用的存储都是mysql，当这些软件系统在生产环境部署时，都会面临一个严峻问题，需要在生产环境中部署一个高可用的mysql集群服务。刚好在最近一周的工作中，需要在kubernetes环境中搭建mysql高可用集群，这里记录一下。 搭建MySQL集群 MySQL的主从半同步复制方案、Galera集群方案以前都也实践过，感觉都不是太友好，配置比较麻烦，而且发生故障转移时经常需要人工参与。所以这里还是采用MySQL官方推荐的Group Replication集群方案。关于MySQL Group Replication集群的架构设计可以看 官方文档 ，懒得看英文的话，也可以看我之前整理出的 资料 。另外kubedb网页上也有介绍 MySQL几种高可用方案的构架方案 ，也比较有意思。 之前的博文 也讲过在非容器环境搭建MySQL Group Replication集群，现在在Kubernetes的容器环境配合kubedb，搭建更方便了，命令如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 # 添加appscode的helm仓库 $ helm repo add appscode https://charts.appscode.com/stable/ $ helm repo update # 部署kubedb $ helm install appscode/kubedb --namespace kube-system --name kube...
阅读全文