KTSee.eu.org

1 、MySQL简介 MySQL 是一个开源的关系型数据库管理系统，使用标准的sql语言，由瑞典 MySQL AB 公司开发，当前属于 Oracle 公司。能够 支持大型的数据库，可以处理上千万条的数据记录。可以运行于在Windows、Linux等多种系统上；支持C、C++、Python、Java、Perl、PHP、Eiffel、Ruby和Tcl等编程语言。对于32位系统，MySQL的表文件最大可支持4GB，对于64位系统，MySQL支持最大的表文件为8TB。 2 、MySQL的高可用方案 本文的MySQL高可用方案为主从复制+读写分离，即由单一的master和多个slave所构成。其中，客户端通过master对数据库进行写操作，通过slave端进行读操作。master出现问题后，可以将应用切换到slave端。 此方案是MySQL官方提供的一种高可用解决方案，节点间的数据同步采用MySQL Replication技术。 MySQL Replication从一个MySQL数据库服务器（master）的数据复制到一个或多个MySQL数据库服务器（slave）。在默认情况下，复制是异步的；slave不需要一直接收来自主机的更新。根据配置，可以复制数据库中的所有数据库、选定的数据库，或者特定的表。 MySQL中复制的优点包括： 扩容解决方案：在多个slave之间扩展负载以提高性能。在这种模式下，所有的写入和更新操作都必须在主服务器上进行。然而，读取操作通过slave镜像。该模型可以提高写入操作的性能，同时，也能够通过增加slave的节点数量，从而显著地提升读取速度。 数据安全：数据从master被复制到slave，并且slave可以暂停复制过程。因此，可以在不损坏master的情况下，在slave上运行备份服务。 分析：现场数据可以在master上创建，而对信息的分析可以在slave进行，而不影响master的性能。 远程数据分发：可以使用复制为远程站点创建本地数据的副本，而不必一直通过访问master。 此高可用的解决方案适用于对数据实时性要求不是特别严格的场景，在使用时可以通过廉价的硬件来扩展slave的节点数量，将读压力分散到多台slave的机器上面。此方案能够在很大的程度上解决数据库读取数据的压力瓶颈问题，这是因为在大多的应用系统中，读压力要比写压...

一、前言 刷机有风险，ROOT需谨慎！搞机不规范，wipe两行泪！ 博主买了一台K30 5G，在使用过程中发现谷歌全家桶在MIUI大陆版上很不正常，非常影响日常使用，经朋友推荐了MIUI EU。虽然Google全家桶都正常了，但是没有小米公交属实有点拉垮，遂决定制作一个Magisk模块，将大陆版MIUI的功能搬到MIUI EU上。 这并不是重复造轮子，就目前而言，博主并没有找到一个本地化模块能将大部分特性移植到MIUI EU，所以自己又写了一个轮子。 二、正文 当前最新版本：v0.33 2020-12-01 请尊重他人的劳动成果，对本模块进行再发布或者修改请不要抹去原作者的信息，转载请注明来源，谢谢。 1.模块介绍 将部分MIUI大陆版特性移植到MIUI EU上。 更新将发布在个人博客 https://blog.minamigo.moe 。 交流QQ群：1012211595 ———— 目前支持的特性有： 小米兰亭Pro字体、小米钱包、应用商店、小爱同学、快应用（未测试）、黄页、传送门、全球上网（一元流量，需要自行从应用商店中安装）。 ———— 部分应用调整为大陆版： 拨号、短信、负一屏、mipush、下载管理（迅雷加速）、日历（农历）。 ———— 注意事项： * 部分应用的广告会回归 * 如果提示需要授权小米智能卡权限，请选择“总是允许”，否则会无法正常工作。如果错误授权，可以清除小米智能卡的数据。 * mipush切换到大陆地区需要手动删除/data/data/com.xiaomi.xmsf 已知问题： * 小爱同学无法使用语音唤醒 * 长按选词翻译功能无法使用 ———— 模块版本：v0.33  系统版本：20.11.18 Android 11 目前未完成的功能： 黄页（可能无法正常工作） 负一屏（未添加） ———————— 当前计划： * 增加可以根据自己需求选择性的恢复本地化功能 * 开始适配Android 11 2.下载安装 此处将不再赘述如何安装Magisk，仅提供下载连接。 Mega网盘： 传送门 阁下可能需要使用代理才能访问mega网盘。如果有朋友可以代传至其它网盘可以与博主联系。 ———— 安装/更新系统顺序： 刷入MIUI EU系统，并成功开机 刷入...

在日常运维工作中，对于系统和业务日志的处理尤为重要。今天，在这里分享一下自己部署的ELK（+Redis）-开源实时日志分析平台的记录过程 （仅依据本人的实际操作为例说明，如有误述，敬请指出） ~ ================概念介绍================ 日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。 通常，日志被分散在储存不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。当务之急我们使用集中化的日志管理，例如：开源的syslog，将所有服务器上的日志收集汇总。 集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，一般我们使用grep、awk和wc等Linux命令能实现检索和统计，但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。 通过我们需要对日志进行集中化管理，将所有机器上的日志信息收集、汇总到一起。 完整的日志数据具有非常重要的作用： 1）信息查找 。通过检索日志信息，定位相应的bug，找出解决方案。 2）服务诊断 。通过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态，找出耗时请求进行优化等等。 3）数据分析 。如果是格式化的log，可以做进一步的数据分析，统计、聚合出有意义的信息，比如根据请求中的商品id，找出TOP10用户感兴趣商品。 开源实时日志分析ELK平台能够完美的解决我们上述的问题， ELK由ElasticSearch、Logstash和Kiabana三个开源工具 组成： 1）ElasticSearch 是一个基于Lucene的开源分布式搜索服务器。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。 在ela...

一、iftop是什么 iftop是类似于top的实时流量监控工具。 作用：监控网卡的实时流量（可以指定网段）、反向解析IP、显示端口信息等 官网： http://www.ex-parrot.com/~pdw/iftop/ 二、界面说明 =>代表发送数据，<= 代表接收数据 TX：发送流量 RX：接收流量 TOTAL：总流量 Cumm：运行iftop到目前时间的总流量 peak：流量峰值 rates：分别表示过去 2s 10s 40s 的平均流量 三、常用参数 -i 指定需要检测的网卡， 如果有多个网络接口，则需要注意网络接口的选择，如：# iftop -i eth1 -B 将输出以byte为单位显示网卡流量，默认是bit -n 将输出的主机信息都通过IP显示，不进行DNS解析 -N 只显示连接端口号，不显示端口对应的服务名称 -F 显示特定网段的网卡进出流量 如iftop -F 192.168.85.0/24 -h 帮助，显示参数信息 -p 以混杂模式运行iftop，此时iftop可以用作网络嗅探器 ; -P 显示主机以及端口信息 -m 设置输出界面中最上面的流量刻度最大值，流量刻度分5个大段显示 如：# iftop -m 100M -f 使用筛选码选择数据包来计数 如iftop -f filter code -b 不显示流量图形条 -c 指定可选的配置文件 如iftop -c config file -t 使用不带ncurses的文本界面， 以下两个是只和-t一起用的： -s num num秒后打印一次文本输出然后退出，-t -s 60组合使用，表示取60秒网络流量输出到终端 -L num 打印的行数 -f 参数支持tcpdump的语法，可以使用各种过滤条件。 四、进入界面后的操作 一般参数 P 切换暂停/继续显示 h 在交互界面/状态输出界面之间切换 b 切换是否显示平均流量图形条 B 切换显示 2s 10s 和 40s 内的平均流量 T 切换是否显示每个连接的总流量 j/k 向上或向下滚动屏幕显示当前的连接信息 f 编辑筛选码 l 打开iftop输出过滤功能 ，如输入要显示...

在 docker 的官方 Registry 中(store.docker.com) 流行的第三方应用在自己的页面中都提供了 dockerfile 的链接. 而很多 dockerfile 的 ENTRYPOINT 命令都是这么写的 ["docker-entrypoint.sh"] 本篇文章就扫盲下 docker-entrypoint.sh 的特殊用法和设计逻辑 MySQL set -e 你写的每个脚本都应该在文件开头加上 set -e , 这句语句告诉bash如果任何语句的执行结果不是 true 则应该退出. 这样的好处是防止错误像滚雪球般变大导致一个致命的错误, 而这些错误本应该在之前就被处理掉. 如果要增加可读性, 可以使用 set -o errexit , 它的作用与 set -e 相同 set -o pipefail 设计用途同上, 就是希望在执行错误之后立即退出, 不要再向下执行了. 而 -o pipefail 的作用域是管道, 也就是说在 Linux 脚本中的管道, 如果前面的命令执行出了问题, 应该立即退出 shopt -s nullglob 在使用 Linux 中的通配符时 * ?等 如果没有匹配到任何文件, 不会报 No such file or directory 而是将命令后面的参数去掉执行 if [ “${1:0:1}” = ‘-‘ ]; then… 这是一个判断语句, 在官方文件中, 上一行已经给出了注释: if command starts with an option, prepend mysqld 这个判断语句是 ${1:0:1} 意思是判断 $1(调用该脚本的第一个参数), 偏移量0(不偏移), 取一个字符(取字符串的长度) 如果判断出来调用这个脚本后面所跟的参数第一个字符是 - 中横线的话, 就认为后面的所有字符串都是 mysqld 的启动参数 上面的这个操作类似于 Python 的字符串切片 set – mysqld “$@” 在上面判断完第一个参数是 - 开头之后, 紧接着就执行了 set -- mysqld "$@" 这个命令. 使用了 set -- 的用法. set — 会将他后面所有以空格区分的字符串, 按顺序分别存储到$1,...

在不同的数据库系统之间做数据同步是大数据领域里常见的需求。一个典型的场景是，业务系统因为需要事务和随机查询，一般会使用 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...

本文是Ebay的架构师在2008年发表给ACM的文章,是一篇解释BASE原则,或者说最终一致性的经典文章. 文中Dan讨论了BASE与ACID原则的基本差异, 以及如何设计大型网站以满足不断增长的可伸缩性需求,期间如何对业务做调整与折衷. 以及一些具体的折衷技术的介绍. 在数据库分区中，以一致性换取可用性会显著提高系统伸缩性。 在过去的十年里，网络应用越来越普及。不管你正在为终端用户还是应用程序开发人员构建应用程序(即服务)，您都希望您的应用程序得到广泛的采用，而广泛采用将会带来交易增长。如果您的应用程序依赖于持久化，那么数据存储可能会成为您的瓶颈。 有两种方法可用于扩展任何应用程序。第一个，也是最简单的，是垂直扩展:将应用程序移动到更大的计算机上。垂直扩展不影响数据的合理性，但是有几个限制。最明显的限制是超过系统的最大可用容量。垂直扩展也很昂贵，因为增加交易容量通常需要购买下一个更大的系统。垂直扩展通常会带来供应商依赖，从而进一步增加成本 水平扩展提供了更多的灵活性，但也相当复杂。水平数据扩展可以沿着两个维度进行。功能扩展，包括按功能分组数据，还有将不同的功能组分布到不同数据库。第二个维度是在功能区域内分割数据，分布到不同数据库，这也叫分片。图1说明了横向数据扩展策略。 如图1所示，水平扩展的两种方法都可以同时应用。用户、产品和事务可以在不同的数据库中。此外，每个功能区域都可以根据交易量跨多个数据库分割。如图所示，功能区域可以相互独立扩展。 功能分区 功能分区对于获得高的可伸缩性非常重要。任何优秀的数据库架构都会将schema分解为按功能分组的表。用户、产品、交易和通信都是功能的例子。利用诸如外键之类的数据库概念是保持这些功能区域一致性的常见方法。 依赖于数据库约束来确保跨功能组的一致性，会导致数据库在部署策略上的高耦合。为了使约束生效，表必须驻留在单个数据库服务器上，从而不能在交易数量增长时水平伸缩。在许多情况下，最简单的扩展方案是将功能组数据移动到相互独立数据库服务器上。 当交易量非常高的时候，不同的功能数据将在不同的数据库服务器。这需要将数据约束从数据库移出并在应用程序解决。这就带来了本文后面将讨论的几个挑战。 CAP原理 加州大学伯克利分校(University of California, Berkeley)教授、Ink...

概述 工作中用到了kafka ,本篇博文整理一下学习到的kafka相关知识，内容多来自网上（主要是官网doc,个人博客），侵删。 kafka 是Linkedin 使用Scala 编写的一个开源的分布式消息系统，当时开发的初衷是为了解决网站活动流数据（比如网页浏览，点击，驻留时间等等）的数据转发处理。因为活动流数据是实时且流量比较大，可想而知kafka 的最大特点就是高吞吐率且容易扩展。 kafka 的设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 Scale out：支持在线水平扩展。 使用场景 从不同的角度出发，kafka的作用也不同。 kafka作为一个消息系统，类比redis,rabbitmq等同类产品， kafka作为一个存储系统，因为进入kafak的消息都会被持久化所以可以作为一个存储系统， kafka作为一个流处理系统，对于流数据，可以在kafka里多次处理，多次流转。 相应的，kafka 的使用场景大致如下： 作为传统消息队列系统的替换。 做metric监控数据的收集处理。 做日志数据的收集处理。 流数据处理。 事件驱动架构的核心组件。 上图中可看出kafka的角色，相应的，kafka也提供了四种核心api: The Producer API allows an application to publish a stream of records to one or more Kafka topics. The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them. The Streams API allows an application to act as a stream processor, consuming an input stream...

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...

看到标题时，有些同学可能会想：“我已经用 xhr 成功地发过很多个 Ajax 请求了，对它的基本操作已经算挺熟练了。” 我之前的想法和你们一样，直到最近我使用 xhr 时踩了不少坑儿，我才突然发现其实自己并不够了解 xhr ，我知道的只是最最基本的使用。 于是我决定好好地研究一番 xhr 的真面目，可拜读了不少博客后都不甚满意，于是我决定认真阅读一遍W3C的 XMLHttpRequest 标准。看完标准后我如同醍醐灌顶一般，感觉到了从未有过的清澈。这篇文章就是参考W3C的 XMLHttpRequest 标准和结合一些实践验证总结而来的。 Ajax 和 XMLHttpRequest 我们通常将 Ajax 等同于 XMLHttpRequest ，但细究起来它们两个是属于不同维度的2个概念。 以下是我认为对 Ajax 较为准确的解释：（摘自 what is Ajax ） AJAX stands for Asynchronous JavaScript and XML. AJAX is a new technique for creating better, faster, and more interactive web applications with the help of XML, HTML, CSS, and Java Script. AJAX is based on the following open standards: Browser-based presentation using HTML and Cascading Style Sheets (CSS). Data is stored in XML format and fetched from the server. Behind-the-scenes data fetches using XMLHttpRequest objects in the browser. JavaScript to make everything happen. 从上面的解释中可以知道： ajax 是一种技术方案，但并不是一种 新技术 。它依赖的是现有的 CSS / HTML / Javascript ，而其中最核心的依赖是浏览器提供的 XMLHttpReques...