在CCleaner中点击注册表,在注册表清理中勾选所有,之后点击扫描问题,然后点击修复选定的问题,重复多次此步骤,直到出现没有发现问题
然后重装就OK了
最近很多朋友跟我抱怨:为了公司数据好看,老板一个劲地想要数据可视化,以为可视化就是画画图表这么简单,可苦了自己天天加班做数据,但其实老板根本不懂可视化!
确实,数据可视化无疑是当今最火热的词,不管是做什么数据,似乎都要拿来做一下可视化才行,但很多人都对数据可视化没有一个具体的概念,也不知道该如何实现可视化。所以,话不多说,下面就带大家由浅入深地学习数据可视化的定义、概念、实现过程和方法。
科学可视化、 信息可视化和可视分析学三个学科方向通常被看成可视化的三个主要分支。而将这三个分支整合在一起形成的新学科 “数据可视化”,这是可视化研究领域的新起点。
广义的数据可视化涉及信息技术、自然科学、统计分析、图形学、交互、地理信息等多种学科。
好的数据库规范有助于减少软件实现的复杂度,降低沟通成本,本铁律主要涵盖了建库建表、建索引、写 SQL、ORM 映射等方面的处理约定。
这篇文章将介绍什么是分布式事务,分布式事务解决什么问题,对分布式事务实现的难点,解决思路,不同场景下方案的选择,通过图解的方式进行梳理、总结和比较。
相信耐心看完这篇文章,谈到分布式事务,不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片,而是能够将知识连成一片,形成知识体系。
介绍分布式事务之前,先介绍什么是事务。
事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交,只要其中任一操作执行失败,都将导致整个事务的回滚。
简单地说,事务提供一种“ 要么什么都不做,要么做全套(All or Nothing)”机制。
多队列网卡顾名思义就是由原来的单网卡单队列变成了现在的单网卡多队列。多队列网卡是一种技术,最初是用来解决网络IO QoS (quality of service)问题的,后来随着网络IO的带宽的不断提升,单核CPU不能完全处满足网卡的需求,体现最为明显的就是单核CPU处理不了网卡大量的数据包请求(软中断)而造成大量丢包,其实当网卡收到数据包时会产生中断,通知内核有新数据包,然后内核调用中断处理程序进行响应,把数据包从网卡缓存拷贝到内存,因为网卡缓存大小有限,如果不及时拷出数据,后续数据包将会因为缓存溢出被丢弃,因此这一工作需要立即完成。剩下的处理和操作数据包的工作就会交给软中断,高负载的网卡是软中断产生的大户,很容易形成瓶颈。但通过多队列网卡驱动的支持,将各个队列通过中断绑定到不同的CPU核上,以满足网卡的需求,这就是多队列网卡的应用。
常见的有Intel的82575、82576,Boardcom的57711等,下面以公司的服务器使用较多的Intel 82575网卡为例,分析一下多队列网卡的硬件的实现以及Linux内核软件的支持。
一、多队列网卡硬件实现
图1.1是Intel 82575硬件逻辑图,有四个硬件队列。当收到报文时,通过hash包头的SIP、Sport、DIP、Dport四元组,将一条流总是收到相同的队列。同时触发与该队列绑定的中断。
从事服务端开发,少不了要接触网络编程。epoll 作为 Linux 下高性能网络服务器的必备技术至关重要,nginx、Redis、Skynet 和大部分游戏服务器都使用到这一多路复用技术。
epoll 很重要,但是 epoll 与 select 的区别是什么呢?epoll 高效的原因是什么?
如何构造出成千上百万的攻城士兵,是高并发测试的关键。而传统压力测试工具设计的时候并不是针对高并发测试设计的。针对高并发场景,传统压力测试工具往往自身是性能瓶颈。为适应高并发趋势,我们设计了TCPBurn,用于无状态协议的高并发压力测试,瞬间可以创造出任意多的攻城的精兵猛将。
我们以消息推送服务为例,来模拟海量用户并发场景。千万并发连接测试相关的公开资料很少,据说要达到C10M(千万连接)并发,需要从根本上解决内核自身的问题。我们的实验希望验证linux服务器环境下Nginx能否承受千万连接的考验。
4.安装R
step1:登录R的官方网站
https://www.r-project.org/
5.安装RStudio
step1:打开RStudio官方网站 https://www.rstudio.com/products/rstudio/download/ 点击Free下的Download
在IM这种讲究高并发、高消息吞吐的互联网场景下,MQ消息中间件是个很重要的基础设施,它在IM系统的服务端架构中担当消息中转、消息削峰、消息交换异步化等等角色,当然MQ消息中间件的作用远不止于此,它的价值不仅仅存在于技术上,更重要的是改变了以往同步处理消息的思路(比如进行IM消息历史存储时,传统的信息系统作法可能是收到一条消息就马上同步存入数据库,这种作法在小并发量的情况下可以很好的工作,但互联网大并发环境下就是灾难)。
MQ消息中间件可以理解一个水池,水池的这头是消息生产者,水池的那头是消息消费者,生产者和消息者无需直接对接,这将带来很多好处:业务解耦、架构分布式化等,生产者和消费者互相完全透明。
但市面上的MQ消息中间件产品很多,作为IM系统中必不可少的一环,我们该如何选型?那么请继续阅读本文。
无论是IM消息通信系统还是客户消息系统,其本质都是一套消息发送与投递系统,或者说是一套网络通信系统,其本质两个词:存储与转发。
推荐:如有兴趣,本文作者的另一篇《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》,适合进行IM群聊架构设计的参考。
要实现一整套能用于大用户量、高并发场景下的IM群聊,技术难度远超IM系统中的其它功能,原因在于:IM群聊消息的实时写扩散特性带来了一系列技术难题。
举个例子:如一个2000人群里,一条普通消息的发出问题,将瞬间写扩散为2000条消息的接收问题,如何保证这些消息的及时、有序、高效地送达,涉及到的技术问题点实在太多,更别说个别场景下万人大群里的炸群消息难题了更别说个别场景下万人大群里的炸群消息难题了。
这也是为什么一般中大型IM系统中,都会将群聊单独拎出来考虑架构的设计,单独有针对性地进行架构优化,从而降低整个系统的设计难度。
本文将分享的是一套生产环境下的IM群聊消息系统的高可用、易伸缩、高并发架构设计实践,属于原创第一手资料,内容较专业,适合有一定IM架构经验的后端程序员阅读。
推荐:如有兴趣,本文作者的另一篇《一套原创分布式即时通讯(IM)系统理论架构方案》,也适合正在进行IM系统架构设计研究的同学阅读。
连接优化需要解决两个核心问题
1. 连接建立耗时较长,导致请求的总时长变长,进而影响用户体验。
2. 在多变的网络环境下,连接建立的过程可能会失败,导致成功率下降,进而影响用户体验。
百度App承载着亿级流量,对于每一个请求都需要追求耗时短,成功率高的体验。从协议角度出发,如何才能做到这一点呢?首先我们来看下建立连接耗时的原理。
网络优化是客户端几大技术方向中公认的一个深度领域,所以百度App给大家带来网络深度优化系列文章,其中包含系列《一》DNS优化,系列《二》连接优化,系列《三》弱网优化,希望对大家在网络方向的学习和实践有所帮助。
百度起家于搜索,整个公司的网络架构和部署都是基于标准的internet协议,目前已经是全栈HTTPS,来到移动互联网时代后,总的基础架构不变,但在客户端上需要做很多优化工作。
DNS(Domain Name System),它的作用是根据域名查出IP地址,它是HTTP协议的前提,只有将域名正确的解析成IP地址后,后面的HTTP流程才能进行,所以一般做网络优化会首选优化DNS。
二、背景
DNS优化核心需要解决的问题有两点:
1.由于DNS劫持或故障造成的服务不可用,进而影响用户体验,影响公司的收入。
2.由于DNS调度不准确导致的性能退化,进而影响用户体验。
百度App承载着亿级流量,每年都会遇到运营商DNS劫持或运营商DNS故障,整体影响非常不好,所以DNS优化刻不容缓,通过下图会更直观的了解运营商劫持或故障的原理。
致性协议中生产环境中应用最多的了。为什么呢?因为他是为 Zookeeper 设计的分布式一致性协议!
1、ZAB 协议全称:Zookeeper Atomic Broadcast(Zookeeper 原子广播协议)。
2、Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面,Zookeeper 并没有使用 Paxos ,而是采用了 ZAB 协议。
3、ZAB 协议定义:ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播 协议。下面我们会重点讲这两个东西。
4、基于该协议,Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间 数据一致性。具体如下图所示:
ODBC 是Open Database Connect 即开放数据库互连的简称,它是由Microsoft 公司于1991 年提出的一个用于访问数据库的统一界面标准,是应用程序和数据库系统之间的中间件。它通过使用相应应用平台上和所需数据库对应的驱动程序与应用程序的交互来实现对数据库的操作,避免了在应用程序中直接调用与数据库相关的操作,从而提供了数据库的独立性。
ODBC 主要由驱动程序和驱动程序管理器组成。驱动程序是一个用以支持ODBC 函数调用的模块,每个驱动程序对应于相应的数据库,当应用程序从基于一个数据库系统移植到另一个时,只需更改应用程序中由ODBC 管理程序设定的与相应数据库系统对应的别名即可。驱动程序管理器可链接到所有ODBC 应用程序中,它负责管理应用程序中ODBC 函数与DLL 中函数的绑定。
ODBC 使用层次的方法来管理数据库,在数据库通信结构的每一层,对可能出现依赖数据库产品自身特性的地方,ODBC 都引入一个公共接口以解决潜在的不一致性,从而很好地解决了基于数据库系统应用程序的相对独立性,这也是ODBC 一经推出就获得巨大成功的重要原因之一。
从结构上分,ODBC 分为单束式和多束式两类。
很多程序员已经体会到了在Windows平台下的ODBC的益处,而在Linux/Unix下进行数据库编程的时候却不得不根据不同的数据库来选择特有的API进行编程,一旦数据库发生了改变,所有与这些API相关的程序都必须进行修改。其实在Linux/Unix下现在也有了自己的ODBC,可以使我们的数据库编程就像在Windows平台下一样简单。
很多场景我们编译C源码,都需要使用gcc4.8及以上版本,比如编译MySQL 8.0、GRPC等,原因是需要支持C++11
。但CentOS 6
其内置版本是gcc4.4。
使用
gcc --version
可以查看版本。
编译问题整理
Valgrind是一组调试(debugging)和剖析(profiling)工具的集合。memcheck是其中应用最广泛的一个,它检查内存有关的问题,包括诸如内存访问越界、内存泄露等。
本文主要通过实际案例介绍如何在CentOS6环境中在线安装PostgreSQL10,安装环境需具备能够使用yum在线安装功能。具体安装步骤如下,
1 下载对应版本的PGDG文件
从https://yum.postgresql.org/repopackages.php页面找到对应的版本,
这里使用https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-6-x86_64/pgdg-centos10-10-2.noarch.rpm
2 安装上述PGDG文件
yum install -y https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-6-x86_64/pgdg-centos10-10-2.noarch.rpm
xChart 是一个 c++/js/html 开发的数据可视化工具,通过SQL语句直接生成数据图表。xChart 通过对数据与图表间的关系建立相应的模型,
以求通过SQL直接查询数据并以图表形式展示,提供一个简单的方便的数据可视化平台。
xChart 在线测试地址:https://xchart.online/
mysql是常用数据库,这篇文章主要给大家介绍了关于mysql中数据统计技巧,对MySQL数据统计相关使用技巧进行归纳总结。
对于程序员来说,大多数人公司都有技术和管理两条发展路线,通常在同一家公司,管理路线的发展可能性,要相对广阔一些;但是技术路线也有技术路线的好处,比如相对而言更依赖于硬实力,因而工作机会丰富。我相信有不少程序员都和我一样,坚守着技术路线,无论是进还是退,都对管理者的岗位没有什么兴趣。
兴许大家都听到软实力和硬实力的概念。对于一个技术人来说,硬实力大致上可以认为是计算机和软件工程相关的技术能力,1 还是 0,是还是非,会不会算法,懂不懂设计,清清楚楚,明明白白; 而软实力则反过来,听起来挺抽象,挺模糊,比如沟通能力,自我管理能力,但是却扮演者重要的角色,甚至随着职业生涯的发展,它的影响力越来越大。而性格,是软实力中一个很特别的影响因素。
Matrix定义了一组用于分散通信的开放API,适用于通过全局开放式服务器联合安全发布,持久化和订阅数据,而无需单一控制点。用途包括即时消息(IM),IP语音(VoIP)信令,物联网(IoT)通信以及将现有通信孤岛联系在一起 - 为新的开放式实时通信生态系统提供基础。
运行环境:centos+mysql8.0.12
1.下载官方打包好的二进制安装包:
#wget https://cdn.mysql.com//Downloads/MySQL-8.0/mysql-8.0.12-linux-glibc2.12-x86_64.tar.xz
可以看到这个版本采用了tar.xz的打包压缩方式,文件只有350M左右,下载还是满方便的。
本文为 Git 学习参考手册。目的是为学习与记忆 Git 使用中最重要、最普遍的命令提供快速翻阅。 这些命令以你可能需要的操作类型划分,并且将提供日常使用中需要的一些常用的命令以及参数。
本手册将从入门到精通指导大家。 首先,我们要从如何以 Git 的思维方式管理源代码开始。
如何以 GIT 的方式思考(这节可以不用看懂,接着看下面的内容,看完就全懂了。)
懂得 Git,第一件重要的事情就是要知道它与 Subversion、Perforce 或者任何你用过的版本控制工具都有着很大的差别。 通常,忘掉你预想的版本控制方式,改以 Git 的方式思考,能够帮助你更好地学习 Git。
让我们从头开始。假设你正在设计一个新的源代码管理系统。在你使用某个工具之前,是如何完成基本的源码版本控制工作的呢? 十有八九,你只是在项目到达某些阶段的时候,对项目做一份拷贝。
$ cp -R project project.bak
这样,你就可以在事情变得一团糟的时候很方便的返回到之前的状态,或者通过对比当前的项目与之前的拷贝,看看自己在之后的工作中,都做了哪些修改。
如果你有点偏执,你可能会经常作上面说的事情,或许还会给项目拷贝加个日期:
$ cp -R project project.2010-06-01.bak
如此,你就有了一堆项目在各个阶段的快照,来作比较、查看。使用这种模式,你还可以有效地与人分享项目变更。 如果你会在项目到达一定阶段的时候给它打个包,丢到自己的网站上,那其他的开发者们,就能很方便地下载它,做点改动,并给你补丁回馈。
$ wget http://example.com/project.2010-06-01.zip
$ unzip project.2010-06-01.zip
$ cp -R project.2010-06-01 project-my-copy
$ cd project-my-copy
$ (做了某些修改)
$ diff project-my-copy project.2010-06-01 > change.patch
$ (通过E-mail发送修改补丁)
以此方式,原先的开发者就能将其他人的改动应用到他的项目中去,其他开发者也能了解你做的变更。其实这便是许多开源项目采用过多年的协作方式。
这办法其实很好使,所以假设我们现在想要写个工具,让这个办法更快、更简单。 我们与其实现一个工具以记录每个文件的版本,可能不如去实现个工具以使创建、储存项目的快照更加方便,不用每次都去人肉作整个项目的拷贝。
这就是 Git 的精要所在。你通过 git commit告诉 Git 你想保存一份项目快照, Git 就会为你的项目中的各个文件的当前状态存一份记录。之后,绝大部分的 Git 命令都围绕这些记录展开。 比如查看它们的区别(diff),提取它们的内容,等等。
题外话:RISE 实验室的前身是赫赫有名的伯克利 AMP 实验室,该实验室曾开发出了一大批大获成功的分布式技术,这些技术对高性能计算产生了深远的影响,包括 Spark、Mesos、Tachyon 等。如今,原 AMP 实验室博士生,同时也是 Spark 和 Mesos 核心作者之一的 Matei 已经转身去了斯坦福,并于去年年底推出了以普及机器学习实践为目的的开源项目 DAWN(详见 AI 前线报道 ),而 RISE 实验室也在没多久后推出了志在取代 Spark 的新型分布式执行框架 Ray(详见 AI 前线报道)。
人类有吃吃喝喝的欲望,也有繁殖后代的欲望。而卡耐基梅隆大学的经济学与心理学教授乔治·勒文斯坦(George Loewenstein)指出,好奇心也是如此。我们对学习的无穷欲望,对发明、探索和不断求知的欲望,“理应和其它欲望具有相同的地位”。
但好奇心的奇特之处在于,它似乎不与任何特定奖励有关。勒文斯坦曾经写道:“好奇心的理论之谜在于,人们为何对那些不会带来任何外在利益的信息如此着迷呢?”人们会追求食物、水、性爱、庇护所、休息、财富、或任何让生命多姿多彩、增添兴味的东西。但分析引力的本质、或登上月球,又有什么好处呢?
随着计算机的日益普及,各种应用每天产生的数据量呈指数级增长。如何存储这些数据,有效处理分析这些数据,并从中提取有价值的信息,是当下迫切需要解决的问题。在过去的十年里,NoSQL在软件工程师阵营里越来越受欢迎,其中最重要的实现是MapReduce ,Bigtable,Cassandra,MongoDB,等产品。 它主要用于解决SQL的可扩展性问题。