IP，操作系统OS，国家，浏览器信息GIF展示图

发布于

图片URL：https://www.wieistmeineip.de/ip-address/

图片URL：https://www.mzwu.com/pic/20070121/ipimg/ipimg.asp

评论

发表评论

此博客中的热门博文

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 的域名添加正确的记录就是了，记录的设置和在原来域...
阅读全文

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）宣发太弱，知名度较低，官网主...
阅读全文

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

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

分布式定时任务对比

发布于
1. 什么是分布式定时任务 把分散的，可靠性差的计划任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫做分布式定时任务。 2. 常见开源方案  elastic-job  ,  xxl-job ， quartz , saturn,  opencron ,  antares    elastic-job elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 ， 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。 Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。 Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案，额外提供资源治理、应用分发以及进程隔离等服务 亮点： 基于quartz 定时任务框架为基础的，因此具备quartz的大部分功能 使用zookeeper做协调，调度中心，更加轻量级 支持任务的分片 支持弹性扩容 ， 可以水平扩展 ， 当任务再次运行时，会检查当前的服务器数量，重新分片，分片结束之后才会继续执行任务 失效转移，容错处理，当一台调度服务器宕机或者跟zookeeper断开连接之后，会立即停止作业，然后再去寻找其他空闲的调度服务器，来运行剩余的任务 提供运维界面，可以管理作业和注册中心。 elastic-job结合了quartz非常优秀的时间调度功能，并且利用ZooKeeper实现了灵活的分片策略。除此之外，还加入了大量实用的监控和管理功能， 以及其开源社区活跃、文档齐全、代码优雅等优点，是分布式任务调度框架的推荐选择。 由于elastic-job-lite  不支持动态添加作业，此处仅贴上elastic-job-Cloud架构图   xxl-job 由个人开源的一个轻量级分布式任务调度框架 ，主要分为 调度中心和执行器两部分 ， 调度中心在启动初始化的时候，会默认生成执行器的RPC代理 对象（http协议调用）， 执行器项目启动之后， 调度中心在触发定时器之后通过jobHand...
阅读全文

打造一个可国内访问的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年了，还不会去注册一个谷歌账号？ 进入控制台，新建一个博客： 绑...
阅读全文

各路 MySQL proxy 功能对比及性能评测

发布于
港真，写下这个文章题目的时候我自己都害怕，因为我对这些 proxy 完全不了解，而且我 TM 也没做过任何 MySQL 相关的性能测试 😂。凡事都有第一次，先列出四种 MySQL proxy ( MySQL Proxy / Atlas / MaxScale / ProxySQL ) 。 上述四个项目的主要目的都是作为代理将 MySQL 请求路由到后端 MySQL Server，从而做到读写分离，所以本文题目将它们统称为 MySQL proxy 。 MySQL Proxy 项目最早出现，并由 MySQL 组织维护，用 MySQL Proxy 作为项目的名字再自然不过了，本文用大小写区分两个术语，希望不会造成读者理解上的偏差。 各路 MySQL proxy 安装及简单使用 在 MySQL 主从复制实践 一文中，笔者给出了主从复制的配置过程，本文复用之前的主从拓扑结构，并在新节点上部署各个 proxy： Name ADDRESS OS MySQL master 10.0.63.202 CentOS7 Ver 14.14 Distrib 5.6.38 slave 10.0.63.203 CentOS7 Ver 14.14 Distrib 5.6.38 proxy 10.0.63.204 CentOS7 not necessary MySQL Proxy 从提交历史来看，MySQL Proxy 项目已不再维护，github 项目主页给出的文档链接提示 Page Not Found ，目前找到的最权威的文档是 mysql-proxy-en.pdf 。 EPEL 源中含有 MySQL Proxy 包，可直接使用 yum 进行安装： [ root@proxy ~]# yum list | grep mysql-proxy mysql-proxy.x86_64 0.8.5-2.el7 ...
阅读全文

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

发布于
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...
阅读全文