动态 版块 发帖 消息 我的
Loading...
HuPei
一切成功均源自积累!
子版块
hupei
63
苹果在凌晨终于发布了公司历史上第二次重大变革,自研处理器M1登场。在40多分钟的发布会上,苹果继续使用十几年来的风格,描绘了一幅极具诱惑的愿景。这幅愿景当然是建立在现实中用户的“痛苦”上。5nm工艺,160亿个晶体管。全新的统一架构,囊括了内存,CPU,GPU,神经网络引擎,缓存。还有一些强悍的数字指标。小米在苹果之后,亦步亦趋的学习苹果发布会的风格。其中数字化性能提升的视觉效果,就是重点之一。虽然作为苹果的深度用户,我不应该说。但这些图片,就是简单的商业吹捧!为什么?3倍,5倍,6倍,15倍性能提升,它的标杆是什么?10年前的电脑,5年前的电脑,现在的电脑。是Windows,还是Mac?苹果语焉不详。我相信苹果是有逻辑的,数字不能拍脑袋就来,但要明火执仗的碾压友商或者现有用户手中的设备,可不是自扇耳光么。所以,这些纸面上的数据,真正对标的是谁,我们并不知道,苹果也不想告诉你。比如这张图:Latest PC Laptop Chip,是那一款呢?10代Intel i7?i9?i5?还是i3?这几款CPU的价格和性能,可是相差很多。在ARM架构CPU这些年的应用中,我们已经知道的结论是,ARM更省电,功耗低。苹果也的确使用了这一点来说明M1的强大。但是我要提醒的是,Intel处理器确实能够从功率提升中获得巨大的好处。当赛场环境限定到定额功率的时候,上面这张图才有意义。也就是说,未来M1处理器想通过功率提升,进一步榨取性能的可能,几乎不存在。或者,投入产出比很低这些当然都是苹果在商业宣传上的熟练技巧。先描绘盛大的愿景吸引眼球,然后不经意间让用户看到现实和理想的差距,进而产生“痛点”,再将价值、性能对比限定到苹果设计好的场景中,碾压一切对标对象。所以,发布会上的神话故事,也要拨开迷雾看真相。M1香吗?在苹果的网页上,对M1芯片的定义是:Small Chip. Giant Leap.M1绝对是苹果寄予厚望的核心产品,未来苹果帝国的基石。从发布的新品来看,Macbook Air,Macbook Pro 13寸,Mac mini,都不是Mac产品线中针对重度商业环境设计的产品。它们主要面对的应用是网页浏览,视频观看,简单的图像、视频编辑。这类用户与其说对性能有要求,不如说更加追求性能和续航之间的平衡。当你在夏天午后,将16寸MBP放在赤裸的大腿上工作30分钟,会对“口干舌燥”,“汗流浃背”这两个成语有船新的认识。使用M1芯片之后,不仅空间上省出了风扇占用的位置,而且续航有了1倍的提升。这次对标对象很清晰,就是苹果使用Intel芯片的同款。Macbook Air续航18小时,Macbook Pro 13寸续航20小时!即使按照使用常识,将指标对折,也能满足1天工作不插电的需求!新的M1芯片主板,集成了所有核心部件:CPU,GPU,内存,缓存,神经网络引擎。它的效能将是传统Wintel架构的xx倍,数字请自己脑补。这种架构确实是在iPhone上验证过,安卓多年没有超越的实际案例。没有“中间商”赚差价的集成系统,当然效能最高。更不用说,M1芯片中的GPU图形处理器,这次可以提供4K视频的编辑能力,让Mac mini的输出从5K到了6K分辨率,确实比老Intel强大。相信Intel的高管在看到这场发布会的时候,很想用鞭子狠狠抽屏幕。“你们丫用了我们这么久,回过头来就是一口,鞭尸起来没完没了。。。”M1芯片另一个巨大的好处是,兼容iOS App。你的iPhone,iPad,喜欢的,顺手的,花了钱不舍得扔的App,统统可以在macOS Big Sur发布之后直接安装到电脑上,想怎么用,就怎么用!还有什么,比无缝对接桌面系统更nb的用户体验呢?哦,对了,锤子也曾经发布过这个概念。可惜,不是每家公司都能把吹过的nb实现。在你冲动之前,再等等!还有些不那么美好的现实。真相:和自由说再见更贵的苹果当我们为M1芯片的集成主板欢呼时,苹果已经把另一根套索悄悄收紧。最后一款可以自由更换内存的Mac mini在发布会后成为绝响。M1芯片集成内存模块,你的内存,以后只能是苹果专供!200刀买8G内存,不说是全世界第一,也是位列头部。好吧,在苹果的Macbook产品线上,这早就不是新闻了。没钱的用户,配不上一台苹果电脑。。。。世界上没什么花钱不能办的事儿!爷有钱不就完了么!不不不,没完。新发布的三款电脑,内存的上限都是16G。你有钱也买不到更大内存的版本。要知道,上一代Mac mini最大支持的内存可是64G,Macbook Pro也一样。难道集成内存的M1,16G就能吊打64G的同门师兄?可能性不大。Macbook Pro早就是集成内存,即便总线效率不如苹果自研主板,但应用程序占用的内存总量是硬指标。比如同时打开50个Chrome标签页,再加上Photoshop和微信电脑端App,就得32G才流畅。所以,第一批尝鲜M1芯片电脑的用户,你们不配32G内存。当然,按照苹果的定位,你们确实也用不上。科幻海量应用在苹果展现的蓝图上,海量iOS应用将填补所有X86不能触达的角落,实现用户体验无缝对接。真相是,在PC端,依然需要X86应用来打天下。你的Office,你的Photoshop,你的各种办公软件,视频编辑器。为什么呢?尽管iOS应用可以安装到M1芯片主机上,但原本适配iPhone屏幕的App,放大到Macbook Air,Macbook Pro 13寸,或者Mac mini连接的各种尺寸显示器上,会是啥样子?竖屏?横屏?像素放大之后的渣屏?你不会想要iOS App在屏幕上还是手机端的样子,它就应该是电脑上的样子!但这需要时间,需要开发者重新做像素适配。苹果说,未来会有三种架构:Universal通用架构,Rosetta 2翻译架构,ARM架构。通用架构需要软件重新编译,横跨ARM和x86架构,以期适应新旧不同平台的Mac。Adobe即将为新Mac打造的,就是这样一套应用。毕竟Photoshop是Mac上最不能放弃的应用。Rosseta 2的架构可以用一句话说清楚,它就是x86程序的虚拟机,让原来mac上的x86应用,通过内置模块翻译之后运行在ARM处理器上。但Rosseta 2背后隐藏的疑虑更多。之所以叫做2,当然因为有1。第一次Rosseta出现,是苹果从PowerPC转到Intel,Rosseta同样是做翻译器。当时的用户碰到什么问题呢?原来在PowerPC上跑得很好的应用,在Intel上只能得到一半的运行速度。还记得微软的Surface吗?Surface同样也有ARM和Intel两种架构的平板电脑。为了保证ARM架构上也能运行x86应用,微软也尝试了虚拟化技术,内置一个类似Rosseta的模块来运行x86程序。结果是,这个模块只能模拟32位的Windows环境,最高内存使用实际不超过3.5G。3.5G内存,呵呵,够干嘛的呢?我们当然希望苹果不会重蹈覆辙,把自己和微软犯过的错误再弄一遍。但也不能忽略基本事实,大量运行良好的mac程序,现在依然是x86核心,还得要Rosseta 2翻译成ARM指令才能运行。那些M1冗余出来的性能,是不是得用在这儿了。快3倍,慢1倍,好像还有的找。别急,Rosseta 2并不是什么都能翻译。涉及到核心硬件架构的代码,它就搞不定,就像Windows平台上的硬件驱动程序一样。那些需要直接与硬件打交道的应用,Rosseta无能为力。比如VMware,Parallel虚拟机,很有可能是安装不到M1芯片的Mac上的。那些买了Mac又要安装Windows的用户,更要死心了!M1芯片的Mac是运转不了Windows的,至少现在还不能。终于可以回答这篇文章的核心问题。苹果M1芯片的新电脑,值得买吗?苹果的一小步,垄断的一大步。M1芯片是苹果里程碑样的基石产品,我对它的前景非常看好。M1针对的移动办公场景,能够完美发挥ARM架构功耗小,性能高的特点,提升用户体验,打造无缝衔接的苹果世界。但是现在,别着急。M1芯片本身不会有太大问题。与之匹配的海量应用,何时才能完美过渡到M1的Mac上,需要时间。苹果给出的时间表是两年,我倒不认为真的需要那么久。明年上半年,期望在mac上赚一笔钱的软件开发者,会将自己的作品逐渐优化,挤占mac应用程序原有的地盘。这又是一场腥风血雨,而开启战端的,正是苹果。苹果正在以一己之力,推动帝国走入新的轨道,所有跟不上的成员都将被无情的抛弃。第一波购买M1芯片mac的,应该是开发者,因为那将是他们的长期饭票。现在进去的用户,会成为垫脚石。用真金白银铺就的垫脚石。
 6    0  12天前
hupei
151
前天有朋友问,为什么买到的硬盘总是比标的容量要小,这个确实是个实际问题,因为我们在做监控项目时,在计算硬盘时,往往会按照硬盘的标的容量来计算,而不是深究它的实际容量,一个4TB的硬盘,它的实际容量往往只有3.7TB这样,为什么呢?今天我们来看下。 一、为什么硬盘标注的容量与实际容量不一样 我们购买硬盘时会发现,硬盘实际的容量会比参数标注的小,例如购买4TB硬盘使用时,点击电脑属性查看硬盘容量,发现容量仅3.72TB,与4TB容量相差0.28TB之多,如果我们在监控项目中,使用的硬盘数量较多的话,那么这个差距就很明显了,这不是骗人么? 硬盘容量涉及十进制和二进制算法之间的换算。其中硬盘厂商为了便于计算采用十进制算法,而电脑则采用二进制算法,它们之间需要进行转换计算。 硬盘厂商十进制计算:4TGB=4000,000MB=4000,000,000KB=4000,000,000,000Byte 操作系统实际二进制计算:4000GB=4096,000MB=4194304000KB=4294,967,296000Byte 1GB的实际字节(Byte)计算:1GB=1024MB*1024KB*1024Byte=1,073,741,824Byte 那么4TB实际容量:4000,000,000,000Byte/(1024MB*1024KB*1024Byte)=3725.29GB=3.72TB 所以,4TB的硬盘容量,我们实际上只能算上3.7TB,这个在监控项目中我们务必要注意。 二、监控硬盘VS普通硬盘 1、 首先什么是监控硬盘?监控硬盘是为常年不间断运行的数据存储系统特殊设计的硬盘。 2、监控硬盘VS普通硬盘 a、连续工作时间监控硬盘设计连续工作时间为7X24小时(每天工作24小时,一周工作7天)。而普通硬盘设计连续工作时间为5X8小时(每天工作8个小时,一周工作5天)如果使用普通盘做全天录像,就相当于让普通硬盘每天都在“加班通宵工作”,使用寿命必然会随之减少! b、功耗与散热监控硬盘≤8W/盘普通硬盘≥14.5W/盘低功耗不仅对电源的压力更小了,而且会减少对散热的压力。监控盘更易保持“冷静”工作! c、启动电流监控硬盘≤2.0安培,优化电源配置普通硬盘≥2.8安培启动电源小了,尤其在多盘位录像机上使用时,就不用担心硬盘太多,启动电流太大,导致电源烧坏的问题! d、抗震性能监控硬盘:多盘系统的专业抗震解决方案普通硬盘:不考虑多盘系统的抗震硬盘非常怕震动,但是硬盘工作时本身也会微微震动。监控硬盘可以避免多块硬盘间相互震动的影响,防止震动造成的损伤! e、传输优化监控硬盘:不间断传输模式,适合码流传输。普通硬盘:间断传输,适合文件传输。录像传输的是源源不断的视频,而普通硬盘间断传输的模式并不合适这种持续的码流传输,有可能导致录像卡顿等问题。 三、监控硬盘的计算 关于监控硬盘的计算,弱电君曾经提到过几次,不过一直以来,都有不少的朋友在问,这里也顺便总结下。 1、计算公式与常见的码流 说到计算,我们要拿什么来计算呢? 除了摄像头数目、需要录像的时间外,还有一个重要的数值:码率! 一般情况下,分辨率越大,码流也就越大,比如我们常用到的200W的摄像头,码流是4MB/S,也就是4096kbps。然后知道了码流、时间、通道数,我们就可以直接套用公式计算了。 公式如下:码率×3600×24÷8÷1024÷1024=1D(一天) 常见码流:我们来解释下这个公式的数值,3600秒就是1小时,24就是一天24小时,8呢,就是字节,1024是将码流转化为MB为单位的,所以要换算G还要除以1024,换成T还要再除1024,就是1天存储量。甲方需要存储多久,再乘以天数就OK了。 以上为H.264的计算方式,现在基本上很少了,那么我们来看一下H.265技术的应用。 2、什么是H.265? 首先,h.265是一种新型技术手段!H.265是一种存在于摄像机和录像机里的技术,随着视频监控的技术发展和社会需求,越来越高的像素带来的不仅仅是清晰度的提升,同时,高像素带来的同样有高硬盘成本和高带宽压力。此刻,H265来了,在保证清晰度的同时,降低了码流。差不多提升了一倍的效率,也就是说对于一般的监控系统来说,H.265可以节约近一半的存储空间,同时降低近一般的网络带宽。 举例:H.264技术下,4个300W存储一个月大概是:60G*4*30=7.2TH.265技术下,4个300W存储一个月大概是:30G*4*30=3.6T 这还是存储的,我们再来看看带宽。以往H.264如果要远程观看1个200W像素的高清画面,可能需要6M的上行带宽,而H.265下,6M网络就可以看一个300W的高清画面。 所以说,降低的成本不只是硬盘存储的,当然还有交换机。 问,支持H.265的设备怎么用?是不是我用老的摄像机接到H.265的录像机上,也能存储减半?NO NO NO !对于网络摄像机和录像机来说,要双方都资持H.265技术才可以。 3、H.265存储怎么计算? 普通h.264 200万摄像机一天大概42G,那是不是直接除以2就可以了呢?其实不然。更简洁的方法来了! 200W≈20G300W≈30G400W≈40G 其实H.265 就是压缩了码流,同样的画质和同样的码率,H.265比H2.64 占用的存储空间要少理论50%,保守估算的话,可以按h.264的60%的存储计算。最后告诉大家一个简单的方法,网上很多计算工具,找个输入摄像机参数立即就出来了,不用这样计算。
 9    0  51天前
hupei
152
AOC 739 是一款商用家用影音类的电脑一体机,24英寸曲面屏,七代I7-7700四核处理器,Intel GMA HD 610显卡,8G内存,120G + 1T双硬盘。默认预装Win10 家庭中文版,但是还是有不少用户想用win7系统,由于英特尔七代处理器在安装Win7系统时,USB3.0设备无法使用,那么PE吧就给大家带来了AOC型号为739的电脑一体机win10改win7图文教程。首先我们需要准备一个USM启动PE盘(USM启动U盘制作方法),并把需要安装的Win7系统放到U盘里。方法/步骤:1、开机,连续按 F2 进入 BIOS 设置页面,选择“Security”,在“Security”页面下找到“Secure Boot”并设置成Disabled,关闭“安全启动”;将secure Boot 改成disabled 关闭安全启动2、移动到“Boot”页面,找到“LaunchCSM”选项,并设置成Enabled,开启兼容模式;将lanch csm改成enabled开启兼容win7模式3、移动到“Boot Option #1”选项,将启动项更改为“UEFI Hard Disk:Windows Boot Manager”;将boot option #1改成uefi hard disk4、移动到“Advanced”页面,找到“SATA Mode Selection”选项,将启动项更改为“AHCI”,按F4保存设置;默认一般改成AHCI5、保存设置后,电脑会自动重启;插入USM启动U盘,在出现开机画面时,按F12启动快捷键,进入启动项选择界面,选择从U盘进入;USM启动U盘6、进入PE启动主菜单后,用键盘的上下键选择 04.启动windows_10PE_x64(精简版,适合常用维护) 进入PE;04.启动windows_10PE_x64(精简版,适合常用维护)7、进入PE后,双击打开桌面上“映像总裁”,选择要安装的Win7系统(映像总裁自动调用CeoMSX导入磁盘控制器及USB3.0驱动,不需要额外集成),点击“下一步”;映像总裁工具8、选择以C盘为系统盘,点击“下一步”;选择以C盘为系统盘,点击“下一步”9、这个时候电脑会自动重启几次,等待软件自动安装Win7系统,就可以进入桌面,重装完成了。安装程序正在安装设备win7系统安装完成以上就是给大家带来的AOC型号为739的电脑一体机win10改win7图文教程
 0    0  52天前
hupei
165
由于新老电脑的装机需求不一样,有些硬盘分区需要用到MBR格式,但是原先的分区格式是GPT格式,那么这篇文章就是PE吧给大家带来的全网最详细的GPT分区和MBR分区转换教程。1、首先进入U盘魔术师的PE桌面;U盘魔术师PE桌面2、既然是转换分区,当然要备份好硬盘资料啦(有条件的话,硬盘重要的资料可以放云盘或者是移动硬盘也可以);既然是转换分区,当然要备份好硬盘资料啦3、打开桌面上“分区工具”,当前为GPT分区格式;当前是GPT分区4、右键点击要转换为MBR格式的硬盘,选择“删除所有分区”;右键点击要转换为MBR格式的硬盘,选择“删除所有分区”5、删除完成后,点击“保存更改”;删除完成后,点击“保存更改”6、再右键点击要转换的硬盘,选择“转换分区表类型为MBR格式”;右键点击要转换的硬盘转换分区表类型为MBR格式7、最后再点击左上方的“保存更改”;点击"保存更改"8、点击顶部工具栏的“快速分区”,按照需要选择分区数目和分区大小;点击快速分区更新需要选择分区数目和大小设定好之后,我们点击确定,就能够快速的对磁盘进行格式化了;9、GPT格式转换成MBR格式完成;GPT格式转换成MBR格式完成10、同样的方法,也能够用来把MBR格式转换成GPT格式分区,右键点击要转换为GPT格式的硬盘,选择“删除所有分区”;右键点击要转换GPT格式的磁盘删除所有分区11、删除分区后,点击保存更改;删除分区后,点击保存更改12、再右键点击要转换的硬盘,选择“转换分区表类型为GUID格式”;转换分区表类型为GUID格式13、然后再点击顶部工具栏的保存更改;保存更改14、点击工具栏上方的“快速分区”,按照需要选择分区数目和分区大小;点击快速分区更具需要选择的分区和数目大小设置好参数之后,就可以点击快速格式化分区;设置好参数之后,就可以点击快速格式化分区15、MBR格式转换成GPT格式完成;MBR格式转换成GPT格式完成以上就是给大家详细介绍的GPT分区和MBR分区转换教程
 0    0  52天前
hupei
286
相对于主机集中式架构,以X86 和云计算为基础、以数据切分为特征的现代分布式架构在扩展性、低成本、降低运行风险等方面的优势明显,已经成为主流的联机交易系统架构方案。3401相对于主机集中式架构,以X86 和云计算为基础、以数据切分为特征的现代分布式架构在扩展性、低成本、降低运行风险等方面的优势明显,已经成为主流的联机交易系统架构方案。本文针对分布式架构在银行核心业务系统中的应用,分享了分库分表、读写分离、数据共享和访问性能优化、高效运维等关键技术方案设计要点。分布式架构概念        各大型国有商业银行经过十多年的发展,都已经实现了数据集中,而且,随着客户服务的不断发展和提升,各家银行核心业务系统的账户量和交易量都已经达到了超大规模,系统的处理能力和性能以及可用性、可靠性、数据一致性、业务连续性等要求极高。在这个过程中,集中式架构发挥了重要作用,各家银行的核心系统基本都构建在集中式架构之上,尤其以大型主机架构为代表。集中式架构下,一般采用纵向扩展的方式即通过增加单机的资源配置来提升系统的处理能力。通过硬件设备和基础软件的集群机制来提升系统的可用性。        本文谈及的分布式架构是指近年来兴起于互联网公司的一种现代分布式架构。分布式架构以X86和云计算为基础、以数据切分(Sharding)、读写分离为特征,采用横向扩展的方式,通过增加服务器的数量,提升系统的处理能力,每个节点都是一个可独立运行的单元,失效时也不会影响应用整体的可用性。另外,系统可以分散到多个节点运行,降低了对单节点的处理能力和可靠性要求,给使用X86服务器替代高性能的主机和小型机服务器创造了条件,可大大降低基础设施的投入成本。        长期以来,银行核心业务系统一直是安全、稳定、可靠的典范。但采用集中式架构的核心业务系统建设费用和运营成本昂贵,随着银行业竞争的加剧,特别是面对采用了低成本分布式架构技术的互联网公司向金融领域的渗透,各大银行都在探索主机迁移方案以节约成本。更大的挑战是随着银行经营转型和业务拓展,核心业务系统的规模急剧扩大,支持的交易模式也更加复杂,核心业务系统处理能力的瓶颈逐渐凸显,需要采取有效措施降低主机负荷,控制运行风险。因此,将分布式架构应用于核心业务系统必然成为各大银行应对上述双重压力的一种选择。困难和挑战        由于分布式架构采用了单体处理能力较小、可靠性较低的常规服务器,与主机或小型机相比存在一些弱点,要将分布式架构应用到银行核心业务系统中,将面临以下困难和挑战。        1.并发处理能力。采用分布式架构的银行核心业务系统一般采用两层结构,即应用服务器层和数据库服务器层,按照SOA的设计原则,部署在应用服务器层的业务逻辑采取服务化和无状态的处理,易于实现横向扩展。而数据库服务器层采取分库分表、读写分离的策略实现处理能力的扩展,如何提高数据库服务器层的并发处理能力是分布式架构在银行核心业务系统应用面临的最大挑战。        2.可用性水平。高可用性是银行核心业务系统最重要的运行指标。各大银行之所以仍然采用主机集中式架构构建核心业务系统,最主要的原因是开放平台比主机的可靠性要低。分布式架构下使用的X86服务器可靠性更低,由于应用服务器层采取了负载均衡及高可用设计,其总体可用性可以达到更高标准。而数据库层采用分库分表和读写分离技术后,也更有利于提高数据库总体可用性,但基础设施包括云平台及网络、存储以及复制、同步软件的可用性将成为主要挑战。            3.交易一致性。交易一致性是银行核心业务系统的基本要求,核心业务系统交易一致性要求远高于电商平台和其他互联网应用。交易一致性指的是数据库事务管理必须满足ACID(原子性Atomic、一致性Consistency、隔离性Isolation、持久性Durability)要求,否则将会发生交易一致性问题。由于分布式架构采取分库分表策略,导致跨库跨表的事务增多,如果采用二阶段提交(Two Phase Commit)机制来进行事务管理,则会引起性能和可用性问题,成为了影响分布式架构在银行核心业务应用的最大障碍。另一个交易一致性问题是由于分布式架构下数据采取读写分离的策略造成的。根据CAP理论:一个系统不能同时满足一致性、可用性和分区容忍性这三个要求。数据库读写分离实际上是要满足分区容忍性,所以可用性和一致性不可能同时得到满足。如何调和因读写分离带来的可用性和一致性矛盾,也是分布式架构设计必须解决的问题。        4.运维复杂度。分布式架构下,采用大量的X86服务器来实现主机或小型机才有的处理能力和高可用性,使得系统的服务器数量急剧膨胀,应用结构和关联关系更为复杂,给运维工作带来巨大挑战。解决方案        分布式架构的核心在于“分”,难点在于“既要能分,也要能合”。下面是分布式架构中几个关键技术方案的设计要点。        图1 分库分表概念模型        1.分库分表策略。常见的分库分表策略包括垂直切分和水平切分。垂直切分是指从业务分析入手,将系统按照不同的业务功能,划分为一些相对独立的子系统或模块。水平切分是指按照一定的逻辑,将数据表按照分区键值进行切分,实现数据的分布式存储。        多数场景下都需要将垂直切分和水平切分联合使用,先对数据进行垂直切分,再针对场景下数据访问特征选择性地进行水平切分(如图1所示)。        2.数据分布算法。可以使用SBF数据分布模型解决分库分表的问题(即Shar d i n g K e y分区键-DataBucket数据桶-TableFamily表族)。其核心思想是应用数据逻辑态与物理态的隔离,从请求数据识别出分区键,然后应用算法确定数据桶的编号,相同编号的数据桶形成一个表族。最后将数据桶映射为物理数据库的表,然后根据数据库的数量,将所有的表族均匀分布到各物理数据库中。        采用一致性“哈希算法”来分库分表,其核心是将要分布的数据经过计算映射到一个具有0~(232-1)的数据空间中,形成一个闭合的环形。然后将物理节点也通过“哈希算法”映射到这个环上,以顺时针方向将所有的对象存储到离自己最近的物理节点上(见图2)。图2 使用SBF 数据分布模型解决分库分表问题        将该算法应用于核心业务系统的数据库分库分表场景下,最重要的就是让应用的数据访问模型与算法特征、数据库特征和数据库物理部署相结合,充分发挥一致性“哈希算法”的优势。        3.数据访问路由。数据访问路由模块的功能是将数据分布算法嵌入到交易流程中,使应用能够透明地访问对应的数据库分库和分表(如图3所示)。图3 数据访问路由模块的功能设计        首先,需要在请求接入时确定应用的分区键,输入是服务的请求数据,然后根据应用场景的不同嵌入分区键的识别逻辑,实现分区键的转换功能。转换后的分区键和计算的桶编号需要写入本交易的内存区,用于后续的分库分表处理。        其次,采用统一的应用访问数据库接口实现数据库访问层,在数据库访问层嵌入数据访问路由逻辑。核心功能包括SQL的解析和重写、多数据源管理、单库数据访问接口等,通过几个模块的协作就可以完成数据访问路由的决策、分发和执行。        4.数据重分布。数据重分布是分库分表后的基本能力要求。重分布过程应该以最大程度地保证应用可用性为前提,避免因为重分布导致全量数据的重组。从服务视角来看,每一次的服务调用,都是针对单一的数据记录进行操作,数据表中存储的也是数据记录。基于关系型数据库进行数据重分布,最好的方式并不是通过记录,而是通过表。将重分布的颗粒度定义到表级别,可以利用数据库的导入导出工具,大大提高数据重分布的效率,降低对系统可用性的影响。        5.数据聚合。跨库查询是分库分表模式下最为典型的应用场景,解决的思路是将查询下发到所有的数据库执行,然后再对结果集进行合并和筛选。方案主要包括并行执行调度、多分区键识别和重组、线程池管理、多数据源管理和数据访问接口、SQL解析和执行计划优化、结果集合并筛选等几个模块。        6.数据共享和访问性能优化。对于读多写少的公共数据,可采用分布式缓存技术实现数据共享,优化访问性能。        但应用缓存也有一个问题,即缓存的数据都存储在内存中,如果出现服务器宕机和进程异常退出的情况,极有可能造成数据丢失。在应用时应该遵循以下几条原则:一是应用缓存的交易必须具有大并发量的特性,放在缓存的数据应当满足只读且使用频繁的条件;二是由于银行业务对可用性的要求,在使用缓存时要在设计时做到应用的高可用,一旦缓存出现问题,应用要能够无缝切换;三是将缓存组件整合到数据访问层,避免对整体业务逻辑的影响。        7.读写分离。数据存在多个副本,包括一个主数据库和多个从数据库。主库负责数据更新和实时数据查询,从库负责历史和准实时的数据查询。分布式架构设计时,可从下面几个层级实现读写分离机制。        组件级:从服务的维度将历史查询和准实时查询从核心应用的主库中隔离出来,在企业级服务总线(ESB)实现组件和交易级的服务路由选择,从而在组件级实现读写分离的要求。        联机服务级:当交易请求通过ESB到核心业务系统后,在请求接入层进行数据访问路由选择,实现交易服务数据访问的读写分离。        数据访问层级:在数据访问层中实现对于SQL语句的解析和识别,如果是可以访问读库的查询功能,则可通过多数据源管理模块路由到读库访问,降低主库的处理压力。        8.可用性保证机制。应用分库分表后,在大幅提升系统处理性能的同时,规避了大型单一集中式数据库的运行风险。可以采取以下几个可用性保证机制。        故障隔离机制:通过“SBF”数据分布模型,准确地识别数据桶编号与物理数据库的对应关系,快速地通过改变物理数据库可用性的标识,实现故障隔离。        集群架构:每个分库仍然应该保持集群架构,利用关系型数据库管理系统的高可用机制进一步提升分库的可用性水平。        数据库的灾备:可以部署灾备数据库,保证极端情况下数据库层的可用性。        9.高效运维。建立分布式架构下的高效运维体系,在资源供给、应用部署、集中监控、故障诊断和应急处置等方面提升自动化水平,是确保分布式架构能够应用和推广的必要条件。 一是通过云平台封装标准PaaS云服务,可实现多套数据库、中间件服务的快速供给及动态伸缩,还可根据主备库配置关系,实现日常检查、一键式切换、服务启停、数据迁移、软件分发、配置管理等自动化操作。二是通过集中监控系统实现从基础设施到应用的全面事件和性能监控,采用规则引擎、可视化引擎、工作流引擎实现事件智能化分析、展现、处置及信息推送,为分布式架构下的快速故障定位、故障自愈和应急处置提供有力的保障。三是通过应用监控系统可度量组件间可用性、性能、流量等指标数据,从而实现端到端交易监控,并实时展现各组件的交易性能、组件间调用关系、追踪单笔交易路径。四是通过大数据技术实时分析系统、数据库、中间件等基础服务和应用服务的性能、容量,动态调整资源,提高资源利用率。分布式架构转型路径        按照整体规划、分步实施、风险可控的策略,推进系统从集中式架构向分布式架构转型。        1.整体架构设计。“新一代”架构的基本特征是企业级、组件化和面向服务,在架构分层的基础上,建设12个应用平台,承接业务架构建模成果,将115个业务组件所对应的应用组件部署在平台上,组件之间通过标准化的服务和事件驱动架构(EDA)进行交互。可以说,应用的解耦为分布式架构的采用提供了极大便利,分布式处理是“新一代”架构所具备的重要能力之一。        2.合理选用平台架构。根据整体架构设计,我们将115个应用组件绝大多数在开放平台上部署,只保留极少的关键核心应用(如存贷款、借记卡、贷记卡等)在主机平台上。        一是对于客户积分管理这类应用,将其全部功能部署在分布式架构平台上。二是对于客户信息这类查询交易为主的应用,将客户信息的维护操作保留在主机上,将客户信息查询下移到分布式架构平台上。三是对于对私存款与借记卡这类应用,其交易量大,数据一致性要求高,目前还很难将其全部迁移到分布式架构平台。基于读写分离的原则,将涉及客户合约、账户、介质维护类的交易保留在主机平台上;将对合约、账户、介质、以及交易明细的查询交易部署到分布式架构平台。主机和分布式平台之间的数据采用日终批量或准实时方式同步。        在组件化、SOA架构特点下,组件之间的服务调用不可避免,因主机技术特点限制,其外呼能力较弱,将此类需要组合主机上存款借记卡服务和开放平台服务的组合场景部署到分布式架构平台,通过交易一致性事中和事后机制保证业务一致性。        3.分布式架构平台研发与应用。如本文所述,将分布式处理的一些关键技术应用在基于X86的分布式架构平台研发上,使其具备高并发、高可用、可扩展的能力。建设银行基于分布式架构的应用已经成功开发和投产,以客户积分管理应用为例,“新一代”3.2期投产后,积分管理的客户数超过6000万,账户数9000万,经过分库分表处理后,数据分布到1024套表中,每套表约存储12万左右的账户记录和相关明细数据,联机日均交易量约为1300万笔,峰值TPS约750,交易平均处理时间约60ms。        4.持续推进分布式架构平台应用。分布式平台的应用显著提升了IT自主可控研发能力,降低了IT成本,下一步将从四个方面深化其应用:一是尝试将贷记卡这类核心应用整体迁移到开放分布式平台;二是推进主机上存款、借记卡、客户信息这类核心应用功能继续向开放分布式平台迁移;三是将一些具有“秒杀”交易特征、突发交易量大的基于小型机的集中式处理系统向x86分布式平台迁移;四是完善分布式架构灾备方案,实现分布式架构平台多活。结语        实践证明,商业银行通过自主设计、自主研发的方式实现分布式技术的应用是可行的。银行引入分布式技术,应对互联网行业竞争,应发挥在网络资源、经营对象、信息安全及线下服务的优势,坚持以自身为主做“银行+互联网”、以开放的态度谋求合作性竞争、以“客户体验至上”为宗旨设计产品提供服务、以积极稳妥的态度推进分布式架构的建设,不断提升银行IT的管理和技术水平。来源:https://blog.csdn.net/sandy_hmily/article/details/81198928
 8    0  75天前
hupei
265
集群概念介绍集群术语须知服务硬件:指提供计算服务的硬件,比如 PC 机、PC 服务器。服务实体:服务实体通常指服务软体和服务硬体。节点(node):运行 Heartbeat 进程的一个独立主机称为节点,节点是 HA 的核心组成部分,每个节点上运行着操作系统和Heartbeat 软件服务。资源(resource):资源是一个节点可以控制的实体,当节点发生故障时,这些资源能够被其他节点接管。如: 磁盘分区、文件系统、IP 地址、应用程序服务、共享存储事件(event):事件也就是集群中可能发生的事情,例如节点系统故障、网络连通故障、网卡故障和应用程序故障等。这些事件都会导致节点的资源发生转移,HA 的测试也是基于这些事件进行的。什么是集群集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源,这些单个的计算机系统就是集群的节点(node)。集群提供了以下关键的特性。(一) 可扩展性。集群的性能不限于单一的服务实体,新的服务实体可以动态的加入到集群,从而增强集群的性能。(二) 高可用性。集群通过服务实体冗余使客户端免于轻易遭遇到“out of service”警告。当一台节点服务器发生故障的时候,这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。(三) 负载均衡。负载均衡能把任务比较均匀的分布到集群环境下的计算和网络资源,以便提高数据吞吐量。(四) 错误恢复。如果集群中的某一台服务器由于故障或者维护需要而无法使用,资源和应用程序将转移到可用的集群节点上。这种由于某个节点中的资源不能工作,另一个可用节点中的资源能够透明的接管并继续完成任务的过程叫做错误恢复。分布式与集群的联系与区别如下:(一) 分布式是指将不同的业务分布在不同的地方。(二) 而集群指的是将几台服务器集中在一起,实现同一业务。(三) 分布式的每一个节点,都可以做集群,而集群并不一定就是分布式的。而分布式,从狭义上理解,也与集群差不多,但是它的组织比较松散,不像集群,有一定组织性,一台服务器宕了,其他的服务器可以顶上来。分布式的每一个节点,都完成不同的业务,一个节点宕了,这个业务就不可访问了。集群主要分成三大类:HA:高可用集群(High Availability Cluster)。LBC:负载均衡集群/负载均衡系统(Load Balance Cluster)HPC:科学计算集群(High Performance Computing Cluster)/高性能计算(High Performance Computing)集群。为什么搭建数据库集群随着经济的高速发展,企业规模的迅猛扩张,企业用户的数量、数据量的爆炸式增长,对数据库提出了严峻的考验。对于所有的数据库而言,除了记录正确的处理结果之外,还面临着以下几方面的挑战。l  如何提高处理速度,实现数据库的均衡负载。l  如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性。l  怎么综合解决这些问题成为众多企业关注的焦点。在数据库上,组建集群也是同样的道理,主要有以下几个原因:(一) 伴随着企业的成长,业务量提高,数据库的访问量和数据量快速增长,其处理能力和计算速度也相应增大,使得单一的设备根本无法承担。(二) 在以上情况下,若扔掉现有设备,做大量的硬件升级,势必造成现有资源的浪费,而且下一次业务量提升时,又将面临再一次硬件升级的高额投入。于是,人们希望通过几个中小型服务器组建集群,实现数据库的负载均衡及持续扩展;在需要更高数据库处理速度时,只要简单的增加数据库服务器就可以得到扩展。(三) 数据库作为信息系统的核心,起着非常重要的作用,单一设备根本无法保证系统的下持续运行,若发生系统故障,将严重影响系统的正常运行,甚至带来巨大的经济损失。于是,人们希望通过组建数据库集群,实现数据库的高可用,当某节点发生故障时,系统会自动检测并转移故障节点的应用,保证数据库的持续工作。(四) 企业的数据库保存着企业的重要信息,一些核心数据甚至关系着企业的命脉,单一设备根本无法保证数据库的安全性,一旦发生丢失,很难再找回来。于是,人们希望通过组建数据库集群,实现数据集的冗余,通过备份数据来保证安全性。数据库集群的分类数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术,这种技术不但能满足应用的需要,而且大幅度的节约了投资成本。数据库集群技术分属两类体系:基于数据库引擎的集群技术和基于数据库网关(中间件)的集群技术。在数据库集群产品方面,其中主要包括基于数据库引擎的集群技术的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE,以及基于数据库网关(中间件)的集群技术的 ICX-UDS 等产品。一般来讲,数据库集群软件侧重的方向和试图解决的问题划分为三大类:l  负载均衡集群(Load Balance Cluster,LBC)侧重于数据库的横向扩展,提升数据库的性能。l  高可用性集群(High Availability Cluster,HAC)侧重保证数据库应用持续不断。大部分的数据库集群侧重与此。l  高安全性集群(High Security Cluster,HSC)侧重于容灾。只有 Oracle RAC 能实现以上三方面可扩展的分布式数据库架构(一) Oracle RAC:其架构的最大特点是共享存储架构(Shared-storage),整个 RAC 集群是建立在一个共享的存储设备之上的,节点之间采用高速网络互联。OracleRAC 提供了非常好的高可用特性,比如负载均衡和应用透明切块(TAF),其最大的优势在于对应用完全透明,应用无需修改便可切换到RAC 集群。但是RAC 的可扩展能力有限,首先因为整个集群都依赖于底层的共享存储,所以共享存储的 I/O 能力和可用性决定了整个集群的可以提供的能力,对于 I/O 密集型的应用,这样的机制决定后续扩容只能是 Scale up(向上扩展)类型,对于硬件成本、开发人员的要求、维护成本都相对比较高。Oracle显然也意识到了这个问题,在 Oracle 的 MAA(Maximum Availability Architecture)架构中,采用 ASM 来整合多个存储设备的能力,使得 RAC 底层的共享存储设备具备线性扩展的能力,整个集群不再依赖于大型存储的处理能力和可用性。RAC 的另外一个问题是,随着节点数的不断增加,节点间通信的成本也会随之增加,当到某个限度时,增加节点可能不会再带来性能上的提高,甚至可能造成性能下降。这个问题的主要原因是 Oracle RAC 对应用透明,应用可以连接集群中的任意节点进行处理,当不同节点上的应用争用资源时,RAC 节点间的通信开销会严重影响集群的处理能力。所以对于使用 ORACLE RAC 有以下两个建议:l  节点间通信使用高速互联网络;l  尽可能将不同的应用分布在不同的节点上。基于这个原因,Oracle RAC 通常在 DSS 环境(决策支持系统Decision Support System ,简称DSS)中可以做到很好的扩展性,因为 DSS 环境很容易将不同的任务分布在不同计算节点上,而对于 OLTP 应用(On-Line Transaction Processing联机事务处理系统),Oracle RAC 更多情况下用来提高可用性,而不是为了提高扩展性。(二) MySQL ClusterMySQL cluster 和 Oracle RAC 完全不同,它采用 无共享架构Shared nothing(shared nothing architecture)。整个集群由管理节点(ndb_mgmd),处理节点(mysqld)和存储节点(ndbd)组 成,不存在一个共享的存储设备。MySQL cluster 主要利用了 NDB 存储引擎来实现,NDB 存储引擎是一个内存式存储引擎,要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上,每个存储节点只保存完整数据的一个分片(fragment)。同时,用户可以设置同一份数据保存在多个不同的存储节点上,以保证单点故障不会造 成数据丢失。MySQL cluster 主要由 3 各部分组成:l  SQL 服务器节点l  NDB 数据存储节点l  监控和管理节点这样的分层也是与 MySQL 本身把 SQL 处理和存储分开的架构相关系的。MySQL cluster 的优点在于其是一个分布式的数据库集群,处理节点和存储节点都可以线性增加,整个集群没有单点故障,可用性和扩展性都可以做到很高,更适合 OLTP 应用。但是它的问题在于:l   NDB(“NDB” 是一种“内存中”的存储引擎,它具有可用性高和数据一致性好的特点。) 存储引擎必须要求数据全部加载到内存之中,限制比较大,但是目前 NDB 新版本对此做了改进,允许只在内存中加 载索引数据,数据可以保存在磁盘上。l  目前的 MySQL cluster 的性能还不理想,因为数据是按照主键 hash 分布到不同的存储节点上,如果应用不是通过主键去获取数据的话,必须在所有的存储节点上扫描, 返回结果到处理节点上去处理。而且,写操作需要同时写多份数据到不同的存储节点上,对节点间的网络要求很高。虽然 MySQL cluster 目前性能还不理想,但是 share nothing 的架构一定是未来的趋势,Oracle 接手 MySQL之后,也在大力发展 MySQL cluster,我对 MySQL cluster 的前景抱有很大的期待。(三) 分布式数据库架构MySQL 5 之后才有了数据表分区功能(Sharding), Sharding 不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。比如 Oracle 的 RAC 是采用共享存储机制,对于 I/O 密集型的应用,瓶颈很容易落在存储上,这样的机制决定后续扩容只能是 Scale Up(向上扩展) 类型,对于硬件成本、开发人员的要求、维护成本都相对比较高。Sharding 基本上是针对开源数据库的扩展性解决方案,很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out,逐渐从 Scale Up 中解放出来。Sharding 架构的优势在于,集群扩展能力很强,几乎可以做到线性扩展,而且整个集群的可用性也很高,部分节点故障,不会影响其他节点提供服务。Sharding 原理简单,容易实现,是一种非常好的解决数据库扩展性的方案。Sharding 并不是数据库扩展方案的银弹,也有其不适合的场景,比如处理事务型的应用它可能会造成应用架构复杂或者限制系统的功能,这也是它的缺陷所在。读写分离是架构分布式系统的一个重要思想。不少系统整体处理能力并不能同业务的增长保持同步,因此势必会带来瓶颈,单纯的升级硬件并不能一劳永逸。针对业务类型特点,需要从架构模式进行一系列的调整,比如业务模块的分割,数据库的拆分等等。集中式和分布式是两个对立的模式,不同行业的应用特点也决定了架构的思路。如互联网行业中一些门户站点,出于技术和成本等方面考虑,更多的采用开源的数据库产品(如 MYSQL),由于大部分是典型的读多写少的请求,因此为 MYSQL 及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业,比如电信业、金融业等,考虑到单点处理能力和可靠性、稳定性等问题,可能更多的采用商用数据库,比如 DB2、Oracle 等。就数据库层面来讲,大部分传统行业核心库采用集中式的架构思路,采用高配的小型机做主机载体,因为数据库本身和主机强大的处理能力,数据库端一般能支撑业务的运转,因此,Oracle 读写分离式的架构相对MYSQL 来讲,相对会少。读写分离架构利用了数据库的复制技术,将读和 写分布在不同的处理节点上,从而达到提高可用性和扩展性的目的。最通常的做法是利用 MySQL Replication 技术,Master DB 承担写操作,将数据变化复制到多台 Slave DB上,并承担读的操作。这种架构适合 read-intensive 类型的应用,通过增加 Slave DB 的数量,读的性能可以线性增长。为了避免 Master DB 的单点故障,集群一般都会采用两台 Master DB 做双机热备,所以整个集群的读和写的可用性都非常高。除了 MySQL,Oracle 从 11g 开始提供 Active Standby 的功能,也具备了实现读写分离架构的基础。读写分离架构的缺陷在于,不管是 Master 还是 Slave,每个节点都必须保存完整的数据,如 果在数据量很大的情况下,集群的扩展能力还是受限于单个节点的存储能力,而且对于 Write-intensive 类型的应用,读写分离架构并不适合。采用 Oracle 读写分离的思路,Writer DB 和 Reader DB 采用日志复制软件实现实时同步; Writer DB 负责交易相关的实时查询和事务处理,Reader DB 负责只读接入,处理一些非实时的交易明细,报表类的汇总查询等。同时,为了满足高可用性和扩展性等要求,对读写端适当做外延,比如 Writer DB 采用 HA 或者 RAC 的架构模式,目前,除了数据库厂商的 集群产品以外,解决数据库扩展能力的方法主要有两个:数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分,类似于 hash 分区 的原理,通过应用架构解决访问路由和Reader DB 可以采用多套,通过负载均衡或者业务分离的方式,有效分担读库的压力。对于 Shared-nothing 的数据库架构模式,核心的一个问题就是读写库的实时同步;另外,虽然 Reader DB只负责业务查询,但并不代表数据库在功能上是只读的。只读是从应用角度出发,为了保证数据一致和冲突考虑,因为查询业务模块可能需要涉及一些中间处理,如果需要在数据库里面处理(取决与应用需求和设计),所以Reader DB 在功能上仍然需要可写。下面谈一下数据同步的技术选型问题:能实现数据实时同步的技术很多,基于 OS 层(例如 VERITAS VVR),基于存储复制(中高端存储大多都支持),基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的 DB 整库同步,会涉及到业务数据选择以及多源整合等问题,因此 OS 复制和存储复制多数情况并不适合做读写分离的技术首选。基于日志的 Oracle 复制技术,Oracle 自身组件可以实现,同时也有成熟的商业软件。选商业的独立产品还是 Oracle 自身的组件功能,这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。采用 Oracle 自身组件功能,无外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard),对比来说,Stream 最灵活,但最不稳定,11g Physical Standby 支持恢复与只读并行,但由于并不是日志的逻辑应用机制,在读写分离的场景中最为局限。如果技术团队对相关技术掌握足够充分,而选型方案的处理能力又能支撑数据同步的要求,采用 Oracle 自身的组件完全可行。选择商业化的产品,更多出于稳定性、处理能力等考虑。市面上成熟的 Oracle 复制软件也无外乎几种,无论是老牌的 Shareplex,还是本土 DSG 公司的 RealSync 和九桥公司的 DDS,或是 Oracle 新贵 Goldengate,都是可供选择的目标。随着 GoldenGate 被 Oracle 收购和推广,个人认为 GoldenGate 在容灾、数据分发和同步方面将大行其道。当然,架构好一个可靠的分布式读写分离的系统,还需要应用上做大量设计,不在本文讨论范围内。(四)  CAP 和 BASE 理论分布式领域 CAP 理论:l  Consistency(一致性), 数据一致更新,所有数据变动都是同步的l  Availability(可用性), 好的响应性能l  Partition tolerance(分区容错性) 可靠性定理:任何分布式系统只可同时满足二点,没法三者兼顾。忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。关系数据库的 ACID 模型拥有 高一致性 + 可用性 很难进行分区:l  Atomicity 原子性:一个事务中所有操作都必须全部完成,要么全部不完成。l  Consistency 一致性. 在事务开始或结束时,数据库应该在一致状态。l  Isolation 隔离层. 事务将假定只有它自己在操作数据库,彼此不知晓。l  Durability. 一旦事务完成,就不能返回。(五)  跨数据库事务2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的,也就是说传统关系型数据库要想实现一个分布式数据库集群非常困难,关系型数据库的扩展能力十分有限。而近年来不断发展壮大的 NoSQL(非关系型的数据库)运动,就是通过牺牲强一致性,采用 BASE 模型,用最终一致性的思想来设计分布式系统,从而使得系统可以达到很高的可用性和扩展性。那么,有没有可能实现一套分布式数据库集群,既保证可用性和一致性,又可以提供很好的扩展能力呢?BASE 思想的主要实现有按功能划分数据库 sharding 碎片BASE 思想主要强调基本的可用性,如果你需要 High 可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE 思想的方案在性能上还是有潜力可挖的。l  共同点:都是关系数据库 SQL 以外的可选方案,逻辑随着数据分布,任何模型都可以自己持久化,将数据处理和数据存储分离,将读和写分离,存储可以是异步或同步,取决于对一致性的要求程度。l  不同点:NOSQL 之类的 Key-Value 存储产品是和关系数据库头碰头的产品 BOX,可以适合非 Java 如 PHP RUBY等领域,是一种可以拿来就用的产品,而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案,不是产品,但这种方式更灵活,更应该是架构师必须掌握的。目前,已经有很多分布式数据库的产品,但是绝大部分是面向 DSS 类型的应用,因为相比较 OLTP 应用,DSS 应用更容易做到分布式扩展,比如基于 PostgreSQL 发展的 Greenplum,就很好的解决了可用性和扩展性的问题,并且提供了很强大的并行计算能力。对于 OLTP 应用,业务特点决定其要求:高可用性,一致性, 响应时间短,支持事务和 join 等等。数据库和 NoSQL当越来越多的 NoSQL 产品涌现出来,它们具备很多关系型数据库所不具备的特性,在可用性和扩展性方面都可以做到很好。第一,NoSQL 的应用场景非常局限,某个类型的 NoSQL 仅仅针对特定类型的应用场景而设计。而关系型数据库则要通用的多,使用 NoSQL 必须搞清楚自己的应用场景是否适合。第二,利用关系型数据库配合应用架构, 比如 Sharding 和读写分离技术,同样可以搭建出具备高可用和扩展性的分布式数据库集群。第三,关系型数据库厂商依然很强大,全世界有大量的 用户,需求必然会推动新的产品问世。第四,硬件的发展日新月异,比如闪存的技术的不断成熟,未来闪存可以作为磁盘与内存之间的 cache,或者完 全替代磁盘。而内存价格越来越低,容量越来越大,In-memory cache 或 database 的应用越来越广泛,可以给应用带来数量级的性能提升。数据库面临的 IO 问题将被极大改善。全文地址来源:https://blog.csdn.net/sandy_hmily/article/details/77847542?utm_source=copy
 0    0  75天前
hupei
291
很多时候比如编程查看代码或者打开各种文档下我们都会用到文本编辑器,Windows自带的记事本功能很简陋并且打开大文件很慢,因此很多童鞋都会有自己喜欢的一款文本编辑器。在这里,西西挑选前15个最佳的文本编辑器,这些编辑器实际上主要适合程序员!如果觉得这些文本编辑器足够您的使用,欢迎点赞,如果还有更好的,可以给我们推荐哦。1. Notepad++中文版:这是 Windows 记事本一个最好的替换产品,优于Windows记事本的一个文本编辑器,完全免费且开源,对于不同的编程语言可以实现语法高亮,代码折叠以及宏,起可定制性非常强。主要特点包括: 开源代码编辑器(Notepad++) v6.9.2 中文免费版 评分:8.6类别: 文本编辑    大小:3.9M    语言: 中文 查看详细信息 >> a. 自动完成b. 语法高亮c. 拖放特性d. 搜索e. 缩放2. PSPad 编辑器:PSPad 是一个Windows平台上免费的适合程序员使用的编辑器。它可以让你保持上一次编辑状态,这样在你下次打开编辑器的时候可以直接显示原来的文件。此外它还支持通过FTP进行远程编辑,支持多文件的比较等。 PSPad editor编辑器 5.0.0(243)绿色中文特别版 评分:6.0类别: 文本编辑    大小:5.8M    语言: 多国语言[中文] 查看详细信息 >> a. 语法高亮b. 支持多文档编辑c. 内建 FTP 客户端d. 完整的十六进制编辑器e. 桌面会话保存3. Emacs (所有平台)Emacs文本编辑器深受高级程序员的喜爱,具有内置的宏功能以及强大的键盘命令,这对于编辑代码来说真是一种享受,这个程序几乎被移植到了每一个平台,并有多个发行版,其中最流行的是GNU Emacs和XEmacs,它们是跨平台、完全免费并且开源。4. Sublime Text3(Windows)Sublime Text3支持但不限于 C, C++, C#, CSS, D, Erlang, HTML, Groovy, Haskell, HTML, Java, JavaScript, LaTeX, Lisp, Lua, Markdown, Matlab, OCaml, Perl, PHP, Python, R, Ruby, SQL, TCL, Textile and XML 等主流编程语言的语法高亮。ST 拥有优秀的代码自动完成功能 (自动补齐括号,大括号等配对符号;自动补全已经出现的单词;自动补全函数名),非常智能; 神级代码编辑软件(Sublime Text 3) V3.3143汉化特别版 评分:5.1类别: 文本编辑    大小:28.4M    语言: 中文 查看详细信息 >> 5. Vim:Vim是从 vi 发展出来的一个文本编辑器。代码补完、编译及错误跳转等方便编程的功能特别丰富,在程序员中被广泛使用。和Emacs并列成为类Unix系统用户最喜欢的编辑器。 VIM文本编辑器 7.4 官方中文安装版 评分:1.9类别: 文件处理    大小:6.4M    语言: 多国语言[中文] 查看详细信息 >> 6. TextMate:Mac 平台下一款强大的文本编辑器,主要特性:a. 代码自动完成b. 可直接在文档中运行 SHELL 命令c. 支持多种风格d. 支持宏e. 目前已提供 Windows 版本7. EditPlus:这是我喜欢的文本编辑器,特点:a. 语法着色b. 多语言支持c. 内建文件浏览器d. 自动完成e. 拼写检查 EditPlus编辑器 V4.10.946 烈火汉化绿色版 评分:4.4类别: 文本编辑    大小:4.0M    语言: 中文 查看详细信息 >> 8. Gedit:这是 Linux 下的一个纯文本编辑器,但你也可以把它用来当成是一个集成开发环境 (IDE), 它会根据不同的语言高亮显现关键字和标识符。9. Notepad2:Notepad2是一个相当优秀的轻量级文本编辑器,开源软件,具有很多特色功能,如代码高亮、编码转换、行号显示、多步Ctrl+Z等,是不可多得的记事本替代方案。而 Notepad2-mod 是 Notepad2 的修改版、更新很及时,支持代码折叠、NSIS、Inno、AHK语法高亮等。 Notepad2中文版 V4.2.25.995 中文绿色版 评分:7.8类别: 文本编辑    大小:1.5M    语言: 中文 查看详细信息 >> 1、自定义语法高亮,支持HTML, XML, CSS, JavaScript, VBScript, ASP, PHP, CSS, Perl/CGI,C/C++, C#, Java, VB, Pascal, 汇编, SQL, Python, NSIS,INI, REG, INF, BAT,DIFF等众多脚本文件。2、支持ANSI,Unicode,UTF-8等编码互换3、可以设置无限个书签(9种图标可换)轻松定位10. UltraEdit:这个工具大家都非常熟悉,不再废话。 UltraEdit-32中文版 v24.10.0.32中文特别增强版 评分:7.9类别: 文本编辑    大小:47M    语言: 中文 查看详细信息 >> 11. TextPad:一款常用的文本编辑器,主要特性:a. 多语言拼写检查b. 自动文本完成c. 宏录制d. 搜索工具条 TextPad编辑器 v7.0.9 特别版 评分:5.0类别: 文本编辑    大小:4.5M    语言: 英文 查看详细信息 >> 12. NoteTab:便携式 HTML 编辑器,支持 Windows,特性:a. 搜索和替换b. Tabbed 接口c. HTML文档格式化d. 高便携,可在 U盘中运行e. 快速可靠13. AkelPad:akelpad 是一款快捷免费且文件小巧的文本编辑软件。具有单窗口单页面和单窗口多页面两种模式,可编辑超过64k限制的文件。支持unicode 字符。支持系统已安装的任意代码页。支持dos/windows 和unix 换行格式。可预览打开的文件,多次撤消,记忆搜索替换设置,支持插件等功能。是一款不错的“记事本”替代工具。 AkelPad(文本编辑器) V4.9.7 中文安装版(x86+x64) 评分:10.0类别: 文本编辑    大小:2.3M    语言: 多国语言[中文] 查看详细信息 >> 14. Nvu:NVU实际上起源于Netscape,还记得那个有点笨拙的HTML编辑器Netscape Composer吗?NVU就是在它的基础上进一步开发出来的,不过,最新版本的NVU已经不是当年的那只丑小鸭,它完全能够胜任专业网页设计工作的需 求。与FrontPage和Dreamweaver这类商业HTML编辑器一样,这款软件(目前支持Windows、Linux和Mac OS平台)同时提供了源代码直接编辑和“所见即所得”这两种网页设计环境。NVU严格遵循W3C联盟的标准,其生成的HTML代码也相当紧凑,它会帮你排除错误或冗余的代码。这款编辑器提供了拼写和语 法检查功能,并且允许你采用不同的主题方案对界面进行定制。你可以自行创建并保存模版,还可以利用内置的FTP客户端把页面迅速上传到Web服务器上。15. E-TextEditor:Windows 下的编辑器,具有以下特性:a. 键盘快捷键b. 自动化以提升性能c. 多语言支持d. 修订版本控制e. 个性化定制
 0    0  75天前
hupei
415
刚装好mysql时,使用正常,后来再次使用时,连接不成功。(虚拟机中) 配置网络有问题, 1、我将ifcfg-*的两个文件备份后删除了。 2、点击右下角的小电脑,重新新建一个网络连接。把网络接入主机的网络,配置虚拟机的ip,掩码和网关。参考(详见文末):https://zhidao.baidu.com/question/570666708.html 3、重启一下网络:systemctl restart network;重启一下mysql:systemctl restart mysqld 4、再连接就成功了。 5、查看mysql 版本:(控制台直接输入指令)mysql -V 注意:子网掩码和网关一定要和局域网中的一样,局域网电脑才能连接到虚拟机的mysql   虚拟机加入到局域网: 1、打开虚拟机的设置,我们在里面修改网络的连接方式。 2、网络连接:选择“桥接模式”直接连接物理网络 3、打开“编辑”下的虚拟网络编辑器 4、如果之前有进行过网络修改设置,但是没有成功的。需要先进行还原默认设置。选择第一项“桥接”,连接选择自动。 5、关闭服务器的防火墙,本地测试不需要开防火墙 6、网络连通测试:通过“ipconfig”命令查看虚拟机IP是否和主机在同一IP段,通过“ping”测试网络。 标签https://www.cnblogs.com/warmlight/p/11640168.html
 12    0  102天前
hupei
359
中标麒麟系统安装rpm文件 打开终端,获得su权限。 cd到rpm所在文件夹,输入指令,rpm -ivh rpm的名称
 0    0  102天前
hupei
394
最近碰到客户反馈一个问题,系统hang了,ssh登录不上,但是可以ping通,通过串口登录进去之后,敲有些命令会卡住,查看cpu负载内存都很正常,手动触发kdump之后看不出死锁/softlockup/hardlockup等异常状态.而且重要的是已经影响到客户几十亿的业务了。我能拿到的只有客户提供的vmcore,为了生活而奔波的人儿赶紧分析起来:系统(SUSE 11SP1)#crash  ./vmcore ./vmlinux-2.6.32.59-0.19-default ./vmlinux-2.6.32.59-0.19-default.gz crash>foreach IN bt > inbt任意找到一个IN(可中断睡眠)的进程 12813 查看堆栈:crash> bt 12813PID:12813  TASK: ffff880262eda140  CPU: 8  COMMAND: "sshd" #0 [ffff880f98e1ba58] schedule atffffffff8139d2a4 #1 [ffff880f98e1bb10] schedule_timeout atffffffff8139d935 #2 [ffff880f98e1bba0] unix_wait_for_peer atffffffff81376e27 #3 [ffff880f98e1bc00] unix_dgram_sendmsg atffffffff813785c2 #4 [ffff880f98e1bcb0] sock_sendmsg atffffffff812e8ddc #5 [ffff880f98e1be50] sys_sendto atffffffff812e9318 #6 [ffff880f98e1bf80] system_call_fastpath atffffffff81002f7b 汇编unix_dgram_sendmsg()crash>dis unix_dgram_sendmsg...2410xffffffff813785b7 <unix_dgram_sendmsg+1143>:   mov   %r13,%rsi2420xffffffff813785ba <unix_dgram_sendmsg+1146>: mov %rbp,%rdi (key1) rdi代表unix_wait_for_peer函数的第一个参数2430xffffffff813785bd <unix_dgram_sendmsg+1149>:   callq 0xffffffff81376da0 <unix_wait_for_peer> 进程12813 unix_wait_for_peer() 函数的堆栈数据:crash>rd -SS ffff880f98e1bba0 -e ffff880f98e1bc00ffff880f98e1bba0:  unix_wait_for_peer+135 0000000000000001ffff880f98e1bbb0:  [ffff880262eda140:task_struct]autoremove_wake_functionffff880f98e1bbc0:  ffff88021ea8bbc0 ffff880238315bc0ffff880f98e1bbd0:  memcpy_fromiovec+87 [ffff880238514980:UNIX]ffff880f98e1bbe0:  [ffff880238514c30:UNIX] [ffff880238514980:UNIX]ffff880f98e1bbf0: [ffff880ff708b630:UNIX] 7fffffffffffffff 汇编unix_wait_for_peer()crash>dis unix_wait_for_peer0xffffffff81376da0<unix_wait_for_peer>:       sub    $0x58,%rsp0xffffffff81376da4<unix_wait_for_peer+4>:     mov    $0x1,%edx0xffffffff81376da9<unix_wait_for_peer+9>:     mov    %r13,0x50(%rsp)0xffffffff81376dae<unix_wait_for_peer+14>:    lea    0x2b8(%rdi),%r130xffffffff81376db5<unix_wait_for_peer+21>:    mov    %rbx,0x38(%rsp)0xffffffff81376dba<unix_wait_for_peer+26>:    mov    %gs:0xa580,%rax0xffffffff81376dc3<unix_wait_for_peer+35>:    mov    %rax,0x8(%rsp)0xffffffff81376dc8<unix_wait_for_peer+40>:    lea    0x18(%rsp),%rax0xffffffff81376dcd<unix_wait_for_peer+45>: mov %rbp,0x40(%rsp) (key2) rbp压入堆栈(0x58-0x40)处,正好是unix_wait_for_peer堆栈中ffff880f98e1bbe8处,即( [ffff880238514980:UNIX])0xffffffff81376dd2<unix_wait_for_peer+50>:    mov    %rdi,%rbx0xffffffff81376dd5<unix_wait_for_peer+53>:    mov    %rsi,%rbp0xffffffff81376dd8<unix_wait_for_peer+56>: mov %r13,%rdi 查看unix_wait_for_peer()函数源码:1005static long unix_wait_for_peer(struct sock *other, long timeo) (key3)1006{1007         struct unix_sock *u = unix_sk(other);1008         int sched;1009         DEFINE_WAIT(wait);1011   prepare_to_wait_exclusive(&u->peer_wait, &wait,TASK_INTERRUPTIBLE);..1019         if (sched)1020                 timeo =schedule_timeout(timeo);10211022         finish_wait(&u->peer_wait,&wait);1023         return timeo;1024} 根据s(key1)(key2)(key3)可以知道12813进程在等待unix_sock(ffff880238514980)crash>struct unix_sock ffff880238514980 | grep peer_wait -A 10  peer_wait = {    lock = {      raw_lock = {        slock = 3369322707      }    },    task_list = {      next = 0xffff880173427bc0,      prev = 0xffff8801877a7bc0    } } 查询出这个unix_sock是系统中的/dev/log文件(由syslog-ng创建,系统中大量需要记录log的进程需要通过这个unix_sock与syslog-ng通信,可以参考mansyslog-ng 和/etc/syslog-ng/syslog-ng.conf 配置文件)crash>struct unix_sock ffff880238514980...dentry= 0xffff880e7634b9c0,...crash>struct dentry 0xffff880e7634b9c0... name = 0xffff880e7634ba60 "log" ...  遍历这个unix_sock的所有等待队列,说明有645个进程正在等待这个unix_sock(ffff880238514980/dev/log)crash>list __wait_queue.task_list  -s__wait_queue.private -H 0xffff880173427bc0 | grep -i private | wc -l645 所有等待unix_sock的进程重定向到一个wait_unix_sock_process文件crash>list __wait_queue.task_list  -s__wait_queue.private -H 0xffff880173427bc0 | grep -i private  > wait_unix_sock_process查询所有的sshd进程crash>ps | grep sshd  7097     1   6  ffff880244cae5c0  IN  0.0   54088   1392 sshd  12813  7097   8  ffff880262eda140  IN  0.0   60148   2900 sshd  19055  7097   2  ffff880ff74c4200  IN  0.0   60148   2900 sshd  21642  7097   1  ffff880262fb4340  IN  0.0   60148   2904 sshd  21958  7097   1  ffff880ffab501c0  IN  0.0   60148   2900 sshd  22459   7097  6  ffff880ff1ed4100  IN  0.0  121052  10272 sshd  22476 22459   0  ffff88022d11a500  IN  0.0  121352   4552 sshd 23334 7097 2 ffff880174b04640 IN 0.0 60148 2900 sshd sshd进程大部分都在wait_unix_sock_process文件中,所以ssh登录之后会卡住查看syslog-ng进程堆栈crash>bt 15232PID:15232  TASK: ffff8801aba90680  CPU: 6  COMMAND: "syslog-ng" #0 [ffff88021ea8ba58] schedule atffffffff8139d2a4 #1 [ffff88021ea8bb10] schedule_timeout atffffffff8139d935 #2 [ffff88021ea8bba0] unix_wait_for_peer atffffffff81376e27 #3 [ffff88021ea8bc00] unix_dgram_sendmsg atffffffff813785c2 #4 [ffff88021ea8bcb0] sock_sendmsg atffffffff812e8ddc #5 [ffff88021ea8be50] sys_sendto atffffffff812e9318 #6 [ffff88021ea8bf80] system_call_fastpath atffffffff81002f7b 查看 unix_wait_for_peer()堆栈数据:crash>rd -SS ffff88021ea8bba0 -e ffff88021ea8bc00ffff88021ea8bba0:  unix_wait_for_peer+135 0000000000000001ffff88021ea8bbb0:  [ffff8801aba90680:task_struct]autoremove_wake_functionffff88021ea8bbc0:  ffff880fce8dfbc0 ffff880f98e1bbc0ffff88021ea8bbd0:  memcpy_fromiovec+87 [ffff880238514980:UNIX]ffff88021ea8bbe0:  [ffff880238514c30:UNIX][ffff880238514980:UNIX] (key4)ffff88021ea8bbf0: [ffff88104c1c3930:UNIX] 7fffffffffffffff 由(key4)可知syslog-ng也是在等待ffff880238514980 unix_sock 所以系统中大量的进程,包括sshd cron等其他的645个进程都在等待unix_sock(/dev/log)(/dev/log由syslog-ng创建),syslog-ng卡住在等这个unix_sock之后,系统中大量的进程都会卡住,包括sshd cron进程等. 但是syslog-ng为什么卡住从vmcore根本看不出来,很可能进程在用户层锁住了.通过查看客户系统中最近安装的软件发现,他们最近安装了两个定制软件,卸载之后系统恢复正常。# /bin/rpm -qa --lastCARKpam-11.01-1.19                    Tue Jun  9 22:49:22 2020CARKaim-11.01-1.5 Tue Jun 9 22:38:48 2020---end来源:https://my.oschina.net/u/4581933/blog/4487064
 0    0  102天前
guest
这是你的故事~
我的小伙伴
Powered by HuPei.net © 2020
虎佩网
您的IP:3.238.190.82,2020-11-28 10:33:42,Processed in 0.03998 second(s).
Powered by HuPei ICP许可证: 鄂ICP备15003222号-1

ICP许可证: 鄂ICP备15003222号-1

支持原创软件,抵制盗版,共创美好明天!