• 关于

    调度操作出问题什么情况

    的搜索结果

问题

浅谈GPU虚拟化技术(三)GPU SRIOV及vGPU调度

福利达人 2019-12-01 22:04:32 4047 浏览量 回答数 0

问题

诊断虚拟机频繁 OOM 的问题

驻云科技 2019-12-01 21:39:51 2749 浏览量 回答数 0

问题

【算法】五分钟算法小知识:贪心算法之区间调度问题

游客ih62co2qqq5ww 2020-05-15 13:57:43 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

如何掌握牢靠Go语言的容器? 容器相对来说更偏重细节一些,如果想掌握的更牢靠的话呢,还是要多看一下代码,重点给大家几个提示 Go语言的并发初步有哪两个特别重要的特点? **GO语言的协程并发操作或者说协程的资源池,其调度策略有两个: ** 1、没有优先级,没有API能设置优先级,正是因为它一切都是靠Go语言自身的一个调度器来听调度,才能保证它的高效率,这点非常重要。 2、调度的策略是可抢占的,假如说一个任务它长时间的占用CPU,那么它是有可能被购入天的这个调度器给其抢占过来,让其其的任务来做运行,这是两个最重要的特点。 GO语言调度的单元goroutine的应用场景是什么? 使用JAVA或者C编写网络程序时,一个线程来处理一个http请求, 但是对于资源的利用率不高。而Go语言实现了轻量级线程的机制,GO语言在底层封装了所有的系统调用,自己实现了一个调度器,这种设计在操作系统的代码中非常多见。比如现代的操作系统基本都会封装一个软件的Timer,同时可以提供上万个软Timer同时工作,而这只是基于数量很少的硬件timer实现的,而GO语言中的并发也是如此,他是基于线程的调度池,这种调度的单元在Go语言中被称为goroutine。 GO语言与其它并发模型最大的区别是什么? 宏观GO语言与其它并发模型最大的不同,就是其推荐使用通信的这种方式来替代共享内存。当资源需要在goroutine之间进行共享的时候,实际上就是这个资源,或者说这个信息通过通道在goroutine之间进行通信的过程。因为这个锁,一般来说都是用在这个共享内存当中的,因为如果说大家阅读GO语言的相关代码,就可以看到这个channel,它实际上是基于锁来保证并发安全。 然而,这也不代表GO语言当中只能使用channel来进行一些操作,其也具备锁这方面的知识。因为现实当中,这个锁还是有一定它现实的意义和现实的要求,因为这个锁它最关键的一个意义就是它能保证资源能在并发的操作当中有一个合理的调度情况和调度策略。其中跟这个最重要,或者说最关联性最强的一个概念就是原子操作。 GO语言中的原子操作具体实现过程是怎样的? 对于原子操作,在其逻辑下,按照它书面的定义上来讲,是指不会被调度器打断的操作。对原子操作实际上就是不存在中间状态的一种操作,要不就全成功,要不全失败,这个在我们在用并发方式来调动某任务,或者说来设计某种并发系统的情况下,这种名字操作我发现是非常重要的设计理念之一。 并发与并行具体概念及实际区分是怎样的? 有一个比较重要的一个概念,就是并发与并行,其实并发与并行,它实际上具体的含义是不一样的,并发实际上是把任务在不同的时间点交给同样一个处理器来进行处理,在同一个时间点,任务不会同时进行,只是任务感觉自己正在执行,因为其那会儿可能正在堵塞状态或者说是就绪状态,其不知道自己被暂停了,以为已经被调度走了,可能自己没有感知,但是实际上CPU所有权已经不在这个任务身上了。 并行比并发更高级一些,它实际上是把每个任务都交给独立的处理器去进行完成,但同一时间点,任务在一定程度上实际上是同时在执行的。一般来说,并发的性能是要比并行更重要一些,在1.5版本之前,我们需要人工去设置GO调度器最多能运行在多少个CPU上,但是在最新的GO版本当中,已经不需要这个相关的操作。 详细介绍一下并发程序中的竞争态? 并发系统设计最初始的这一个概念就是并发程序设计当中一个竞合的概念,或者也叫竞争态。假如说我要记录一个文件的阅读量,但是这个文件或者说这个网页,可能它的阅读渠道有非常多,有可能通过引擎通过微信通过APP等等这些渠道,这些渠道的话呢,它的阅读也都是并发的,这就会涉及到同样一个变量,被多个协程的所共同访问的情况。具体代码如下: 对于GO语言并发体系中的主推的通信机制是什么? channel是GO语言并发体系中的主推的通信机制,它可以让一个 goroutine 通过它给另一个 goroutine 发送值信息。每个 channel 都有一个特殊的类型,也就是 channels 可发送数据的类型。一个可以发送 int 类型数据的 channel 一般写为 chan int。 GO语言当中,它实际上是大家协同的机制,通过这种方式让几个goroutine之间做达到一个协调的效果,那么每个goroutine当中,实际上channel都是一个特殊的类型,它实际上是可以发送数据。比如现在想发送一个int类型的数据,那么channel就要定义一个发送int数据的一个管道。 那么GO语言当中,提倡使用通讯的方式来代替共享内存的方式来做goroutine,或者说并发之间的一个协同。channel如果我们后续阅读它的代码就会知道,它是保证协程安全,并且它遵循这个先入先出的原则来让这个储蓄方读取获得数据,而且它能保证顺序,正是这两个特性,可以让这个channel替代共享内存,因为它的如果顺序有所改变的话,它实际上也是有会有问题。 详细介绍GO语言中关于通道的声明涉及哪些方面? 1.经典方式声明 通过使用chan类型,其声明方式如下: var name chan type 其中type表示通道内的数据类型;name:通道的变量名称,不过这样创建的通道只是空值 nil,一般来说都是通道都是通过make函数创建的。 2.make方式 make函数可以创建通道格式如下: name := make(chan type) 3.创建带有缓冲的通道 后面会讲到缓冲通道的概念,这里先说他的定义方式 name := make(chan type, size) 其中type表示通道内的数据类型;name:通道的变量名称,size代表缓冲的长度。 具体介绍通道数据收发的详细过程有哪些? 通道的数据发送 通道当中发送数据的操作服务是这样的这样的一个大于号加上一个减号。 chan <- value 注意,如果是发送给一个没有缓冲的一个通道。假如说数据没有被接收的话,那么这个发送操作将持续被注册,也就是说就是channel这个语句就直接被注册到这,假如说没有任何的协程去读到他或者其他语句去读到这个产品,那么这个语句就被注册掉了。但GO语言是能发现的,如果其一直在堵塞的话,那实际上就造成死锁,GO语言的编译器实际上能发现的有点错误。 假如说,首先创建一个int型的通道,然后直接尝试发送一个数据给它,编译会报错,然后呢,数据的这个数据的接收的话,实际上就是把这个点号的位置跟那个大于号的位置做了一个调换。其实把这个双方的位置做了一个调换之后,是实际上就是都做了一个允许的操作。这其中的话呢,还有一种比较特殊的一个读取操作是其可以忽略到接收到的数据,因为不管管道中发出的数据,如果没读的话就堵塞到这,那么如果你觉得这个语句你也不需要,那么你可以把那个变量给它忽略掉。 2.通道的数据接收 通道接收数据的操作符也是<-,具体有以下几种方式 - 1) 阻塞接收数据 阻塞模式接收数据时,将接收变量作为<-操作符的左值,格式如下: data := <-ch 执行该语句时将会阻塞,直到接收到数据并赋值给 data 变量。 如需要忽略接收的数据,则将data变量省略,具体格式如下: <-ch - 2) 非阻塞接收数据 使用非阻塞方式从通道接收数据时,语句不会发生阻塞,格式如下: data, ok := <-ch 非阻塞的通道接收方法可能造成高的 CPU 占用,因此使用非常少。一般只配合select语句配合定时器做超时检测时使用。 关于通道数据收发有哪些需要注意的事项? 通道数据在进行输入收发的时候,必须要在两个不同的goroutine当中进行,因在同一个goroutine当中,收发的这些语句实际上都是堵塞的,你可能在同一个goroutine当中,它的这个函数已经在那边阻塞住了,或者说程序已经在那边阻塞住了,它已经停在那了,你后面有一句你能执行不到,所以说通道的收发必须在两个不同的goroutine之间来进行,在同一个goroutine之间的这个收发操作的话,实际上是没有意义的。 接收将持续堵塞,直到发送方发送出去,如果接收方接收,然后通道中没有发送方数据时,接收方也会发送,直到发送方到发送数据为止。就是刚才说的这个一体两面,这个发送方假如说没有人读的话,发送方会堵塞,假如说没有人写的话,那么接收方也会发生堵塞,这两边实际上都会有一个堵塞的情况。那么这个通道的收发的话呢,一般来说一次只能收一一个元素,假如说这个是一个有缓冲的一个通道,我通过一次不操作的话,实际上也只不过读出一个元素。不能把它一些缓冲区所有元素都读出来。 聊一下生产者消费者模式具体内容有哪些? 介绍一下生产者消费者模式,从GO语言的这个并发模型来看,也就是说假如说咱们站在一个比较高的一个高度来看,其实利用channel的确能达到共享内存的目的。这个channel的性质与在读写状态且保证顺序的共享内存并无不同。甚至我们可以说这个是基于消息队列的封装程度可以比共享内存来的更安全,所以说呢,这个在这个GO语言当中,或者说在GO语言的这个设计风格当中的话呢,其这个生产者消费者模式实现起来会相对来说比较简单一些。我们先介绍一下什么是生产者消费者。 就这个这这张图当中的话呢,就是一个典型的那种消费的问题, 就是说我是生产者的话我会生产一些产品,然后放到这个仓库当中,消费者的话会从那个仓库当中去取商品,这个可以说是消息队列,还有包括卡夫卡那些比较经典的相应队列当中,都会用到的这么一个设计模式,或者说其们从本质上来说的话,都是基于这样一个设计模式,交易的生产者是谁?消费者是谁?这个消息队列的话是。这个生产者消费者模式的话呢,实际上也成为有缓冲有限缓冲问题,它是一个并发的一个经典的案例,因为我们知道这个商品仓库的库房大小是有限的,也就是说生产者不能无限的去生产商品,一旦这个库房爆掉的话,它是它是必须要中止自己的生产,消费者也是不能无限地获取消息。 假如仓库是空的话,那这个消费者的这个相关的情况也需要被阻塞。那么怎么在这个生产者跟消费者之间保证商品不丢失。这就是生产者与消费者之间最核心的内容。先来看一下这个Java当中生产者消费者的这种实现到底是什么样的。这个可以说是一个最经典的这么样一个实现。这个Java当中是没有channel,那么它只能通过什么呢,只能通过信号量和一个一个log,也就是说一个忽视服务态度,这两个这两个配合信号量和所配合才能共同完成,这样一个生产者消费者这么一个相关的工作。 GO语言并发实战详细过程梳理 在现在这个远程办公的这一个大的背景下,积累了大量重复的文件,因为很可能大家都不断的在不同的群里发相同的文件,发相同的这个报表,以及一些相同的视频等等这些需要学习的材料,那么怎么把这些文件都找出来,然后把这些相同文件都给删掉了,这实际上是并发课的一个实践的一个内容,因为这个创业型的这个方案的话,它的代码相对来说比较长。 如何使用GO语言清理PC机中的文件,详细代码及注释如下: package main import ( // "fmt" // fmt 包使用函数实现 I/O 格式化(类似于 C 的 printf 和 scanf 的函数), 格式化参数源自C,但更简单 "io/ioutil" //"sync" //"time" ) func PrintRepreatFile(path string, fileNameSizeMap map[string]int64, exFileList []string) { fs, _ := ioutil.ReadDir(path) for _, file := range fs { if file.IsDir() { PrintRepreatFile(path+"/"+file.Name(), fileNameSizeMap, exFileList)//遍历整个文件系统,如果是目录则递归调用 } else { if file.Size() > 1000000 {//设定文件清理阈值,如果大于一定大小再进行清理 fileSize := fileNameSizeMap[file.Name()]//通过查哈希表的方式来确定,有无重名且大小相同的文件。 if fileSize == file.Size() { fmt.Println(path + "/" + file.Name())//如果有则打印出来 exFileList = append(exFileList, path+file.Name())//将结果记入切片当中 } else { fileNameSizeMap[file.Name()] = file.Size() } } } } } func main() { //方式一 fileNameSizeMap := make(map[string]int64, 10000) exFileList := make([]string, 100, 1000) PrintRepreatFile("E:/test", fileNameSizeMap, exFileList) } 这个程序在GO语言的环境下可以直接运行使用,其中有几个知识点,也是咱们前文提到过的,首先是切片的大小一定要设定的相对合适一些,如果容量不够大造成频繁扩容非常浪费资源。二是哈希表也就是map没有并发安全的属于,在我们这个未引入并发的程序中可以使用,如果有并发操作,那么map不再适用了。 可能很多人被GO语言的在并发性能所吸引入坑的,GO语言之父也就是UNIX之父Ken Thompson明显给出了很多建议,根据笔者在操作系统方面的相关经验来看,GO语言设计中经常参考UNIX内核的设计思路。比如硬定时器的数量有限,无法满足系统实际运行需要,所以在内核代码中就会看到基于硬件定时器的软件定时器的方案,而软件定时器的数量可以比硬件定时器多几百倍。 这样的理念明显融合到了 goroutine之中,由于其它编程语言往往直接通过系统级别的线程来实现并发功能,但是这样的方式往往会是大马拉小车,造成系统资源的浪费。因此GO语言封装了所有的系统操作,实现了更加轻量级的协程-goroutine。只要使用关键字(go)就可以启动协程,对比C++、JAVA的多线程并发模型,GO的协程更简单明了。 当然协程之间的消息通信与并发控制也是非常重要的一环。在GO语言借鉴了Message Queue的消息队列机制替代共享内存的方式进行协程间通信,其中管道channel作为基本的数据类型,保证并发时的操作安全。而且管道的引入还带来很多实践中非常实用的功能,比如可以方便实现生产者、消费者等并发设计模式,而这些设计模式在其它使用共享存内存的并发模型中实现起相关功能来非常的繁锁。 在GO语言中在调用函数前加入go 关键字,就能启动一个协程,也就是一个并发,但是我们上面的程序如果把调用方式改为: go PrintRepreatFile("E:/test", fileNameSizeMap, exFileList) 你会发现程序会直接退出,什么都没做,所以GO语言的并发对于初学者来说还是有一定门槛的,比如上例中如果想设计成一个并行的程序,如何让多个协程共同来帮忙找出重复的文件其实还是要费一番周折的。

剑曼红尘 2020-04-13 11:06:46 0 浏览量 回答数 0

回答

如果对什么是线程、什么是进程仍存有疑惑,请先Google之,因为这两个概念不在本文的范围之内。 用多线程只有一个目的,那就是更好的利用cpu的资源,因为所有的多线程代码都可以用单线程来实现。说这个话其实只有一半对,因为反应“多角色”的程序代码,最起码每个角色要给他一个线程吧,否则连实际场景都无法模拟,当然也没法说能用单线程来实现:比如最常见的“生产者,消费者模型”。 很多人都对其中的一些概念不够明确,如同步、并发等等,让我们先建立一个数据字典,以免产生误会。 多线程:指的是这个程序(一个进程)运行时产生了不止一个线程 并行与并发: 并行:多个cpu实例或者多台机器同时执行一段处理逻辑,是真正的同时。 并发:通过cpu调度算法,让用户看上去同时执行,实际上从cpu操作层面不是真正的同时。并发往往在场景中有公用的资源,那么针对这个公用的资源往往产生瓶颈,我们会用TPS或者QPS来反应这个系统的处理能力。 并发与并行 线程安全:经常用来描绘一段代码。指在并发的情况之下,该代码经过多线程使用,线程的调度顺序不影响任何结果。这个时候使用多线程,我们只需要关注系统的内存,cpu是不是够用即可。反过来,线程不安全就意味着线程的调度顺序会影响最终结果,如不加事务的转账代码: void transferMoney(User from, User to, float amount){ to.setMoney(to.getBalance() + amount); from.setMoney(from.getBalance() - amount); } 同步:Java中的同步指的是通过人为的控制和调度,保证共享资源的多线程访问成为线程安全,来保证结果的准确。如上面的代码简单加入@synchronized关键字。在保证结果准确的同时,提高性能,才是优秀的程序。线程安全的优先级高于性能。 好了,让我们开始吧。我准备分成几部分来总结涉及到多线程的内容: 扎好马步:线程的状态 内功心法:每个对象都有的方法(机制) 太祖长拳:基本线程类 九阴真经:高级多线程控制类 扎好马步:线程的状态 先来两张图: 线程状态 线程状态转换 各种状态一目了然,值得一提的是"blocked"这个状态:线程在Running的过程中可能会遇到阻塞(Blocked)情况 调用join()和sleep()方法,sleep()时间结束或被打断,join()中断,IO完成都会回到Runnable状态,等待JVM的调度。 调用wait(),使该线程处于等待池(wait blocked pool),直到notify()/notifyAll(),线程被唤醒被放到锁定池(lock blocked pool ),释放同步锁使线程回到可运行状态(Runnable) 对Running状态的线程加同步锁(Synchronized)使其进入(lock blocked pool ),同步锁被释放进入可运行状态(Runnable)。 此外,在runnable状态的线程是处于被调度的线程,此时的调度顺序是不一定的。Thread类中的yield方法可以让一个running状态的线程转入runnable。内功心法:每个对象都有的方法(机制) synchronized, wait, notify 是任何对象都具有的同步工具。让我们先来了解他们 monitor 他们是应用于同步问题的人工线程调度工具。讲其本质,首先就要明确monitor的概念,Java中的每个对象都有一个监视器,来监测并发代码的重入。在非多线程编码时该监视器不发挥作用,反之如果在synchronized 范围内,监视器发挥作用。 wait/notify必须存在于synchronized块中。并且,这三个关键字针对的是同一个监视器(某对象的监视器)。这意味着wait之后,其他线程可以进入同步块执行。 当某代码并不持有监视器的使用权时(如图中5的状态,即脱离同步块)去wait或notify,会抛出java.lang.IllegalMonitorStateException。也包括在synchronized块中去调用另一个对象的wait/notify,因为不同对象的监视器不同,同样会抛出此异常。 再讲用法: synchronized单独使用: 代码块:如下,在多线程环境下,synchronized块中的方法获取了lock实例的monitor,如果实例相同,那么只有一个线程能执行该块内容 复制代码 public class Thread1 implements Runnable { Object lock; public void run() { synchronized(lock){ ..do something } } } 复制代码 直接用于方法: 相当于上面代码中用lock来锁定的效果,实际获取的是Thread1类的monitor。更进一步,如果修饰的是static方法,则锁定该类所有实例。 public class Thread1 implements Runnable { public synchronized void run() { ..do something } } synchronized, wait, notify结合:典型场景生产者消费者问题 复制代码 /** * 生产者生产出来的产品交给店员 */ public synchronized void produce() { if(this.product >= MAX_PRODUCT) { try { wait(); System.out.println("产品已满,请稍候再生产"); } catch(InterruptedException e) { e.printStackTrace(); } return; } this.product++; System.out.println("生产者生产第" + this.product + "个产品."); notifyAll(); //通知等待区的消费者可以取出产品了 } /** * 消费者从店员取产品 */ public synchronized void consume() { if(this.product <= MIN_PRODUCT) { try { wait(); System.out.println("缺货,稍候再取"); } catch (InterruptedException e) { e.printStackTrace(); } return; } System.out.println("消费者取走了第" + this.product + "个产品."); this.product--; notifyAll(); //通知等待去的生产者可以生产产品了 } 复制代码 volatile 多线程的内存模型:main memory(主存)、working memory(线程栈),在处理数据时,线程会把值从主存load到本地栈,完成操作后再save回去(volatile关键词的作用:每次针对该变量的操作都激发一次load and save)。 volatile 针对多线程使用的变量如果不是volatile或者final修饰的,很有可能产生不可预知的结果(另一个线程修改了这个值,但是之后在某线程看到的是修改之前的值)。其实道理上讲同一实例的同一属性本身只有一个副本。但是多线程是会缓存值的,本质上,volatile就是不去缓存,直接取值。在线程安全的情况下加volatile会牺牲性能。太祖长拳:基本线程类 基本线程类指的是Thread类,Runnable接口,Callable接口Thread 类实现了Runnable接口,启动一个线程的方法:  MyThread my = new MyThread();  my.start(); Thread类相关方法:复制代码 //当前线程可转让cpu控制权,让别的就绪状态线程运行(切换)public static Thread.yield() //暂停一段时间public static Thread.sleep() //在一个线程中调用other.join(),将等待other执行完后才继续本线程。    public join()//后两个函数皆可以被打断public interrupte() 复制代码 关于中断:它并不像stop方法那样会中断一个正在运行的线程。线程会不时地检测中断标识位,以判断线程是否应该被中断(中断标识值是否为true)。终端只会影响到wait状态、sleep状态和join状态。被打断的线程会抛出InterruptedException。Thread.interrupted()检查当前线程是否发生中断,返回booleansynchronized在获锁的过程中是不能被中断的。 中断是一个状态!interrupt()方法只是将这个状态置为true而已。所以说正常运行的程序不去检测状态,就不会终止,而wait等阻塞方法会去检查并抛出异常。如果在正常运行的程序中添加while(!Thread.interrupted()) ,则同样可以在中断后离开代码体 Thread类最佳实践:写的时候最好要设置线程名称 Thread.name,并设置线程组 ThreadGroup,目的是方便管理。在出现问题的时候,打印线程栈 (jstack -pid) 一眼就可以看出是哪个线程出的问题,这个线程是干什么的。 如何获取线程中的异常 不能用try,catch来获取线程中的异常Runnable 与Thread类似Callable future模式:并发模式的一种,可以有两种形式,即无阻塞和阻塞,分别是isDone和get。其中Future对象用来存放该线程的返回值以及状态 ExecutorService e = Executors.newFixedThreadPool(3); //submit方法有多重参数版本,及支持callable也能够支持runnable接口类型.Future future = e.submit(new myCallable());future.isDone() //return true,false 无阻塞future.get() // return 返回值,阻塞直到该线程运行结束 九阴真经:高级多线程控制类 以上都属于内功心法,接下来是实际项目中常用到的工具了,Java1.5提供了一个非常高效实用的多线程包:java.util.concurrent, 提供了大量高级工具,可以帮助开发者编写高效、易维护、结构清晰的Java多线程程序。1.ThreadLocal类 用处:保存线程的独立变量。对一个线程类(继承自Thread)当使用ThreadLocal维护变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,所以每一个线程都可以独立地改变自己的副本,而不会影响其它线程所对应的副本。常用于用户登录控制,如记录session信息。 实现:每个Thread都持有一个TreadLocalMap类型的变量(该类是一个轻量级的Map,功能与map一样,区别是桶里放的是entry而不是entry的链表。功能还是一个map。)以本身为key,以目标为value。主要方法是get()和set(T a),set之后在map里维护一个threadLocal -> a,get时将a返回。ThreadLocal是一个特殊的容器。2.原子类(AtomicInteger、AtomicBoolean……) 如果使用atomic wrapper class如atomicInteger,或者使用自己保证原子的操作,则等同于synchronized //返回值为booleanAtomicInteger.compareAndSet(int expect,int update) 该方法可用于实现乐观锁,考虑文中最初提到的如下场景:a给b付款10元,a扣了10元,b要加10元。此时c给b2元,但是b的加十元代码约为:复制代码 if(b.value.compareAndSet(old, value)){ return ;}else{ //try again // if that fails, rollback and log} 复制代码 AtomicReference对于AtomicReference 来讲,也许对象会出现,属性丢失的情况,即oldObject == current,但是oldObject.getPropertyA != current.getPropertyA。这时候,AtomicStampedReference就派上用场了。这也是一个很常用的思路,即加上版本号3.Lock类  lock: 在java.util.concurrent包内。共有三个实现: ReentrantLockReentrantReadWriteLock.ReadLockReentrantReadWriteLock.WriteLock 主要目的是和synchronized一样, 两者都是为了解决同步问题,处理资源争端而产生的技术。功能类似但有一些区别。 区别如下:复制代码 lock更灵活,可以自由定义多把锁的枷锁解锁顺序(synchronized要按照先加的后解顺序)提供多种加锁方案,lock 阻塞式, trylock 无阻塞式, lockInterruptily 可打断式, 还有trylock的带超时时间版本。本质上和监视器锁(即synchronized是一样的)能力越大,责任越大,必须控制好加锁和解锁,否则会导致灾难。和Condition类的结合。性能更高,对比如下图: 复制代码 synchronized和Lock性能对比 ReentrantLock    可重入的意义在于持有锁的线程可以继续持有,并且要释放对等的次数后才真正释放该锁。使用方法是: 1.先new一个实例 static ReentrantLock r=new ReentrantLock(); 2.加锁       r.lock()或r.lockInterruptibly(); 此处也是个不同,后者可被打断。当a线程lock后,b线程阻塞,此时如果是lockInterruptibly,那么在调用b.interrupt()之后,b线程退出阻塞,并放弃对资源的争抢,进入catch块。(如果使用后者,必须throw interruptable exception 或catch)     3.释放锁    r.unlock() 必须做!何为必须做呢,要放在finally里面。以防止异常跳出了正常流程,导致灾难。这里补充一个小知识点,finally是可以信任的:经过测试,哪怕是发生了OutofMemoryError,finally块中的语句执行也能够得到保证。 ReentrantReadWriteLock 可重入读写锁(读写锁的一个实现)   ReentrantReadWriteLock lock = new ReentrantReadWriteLock()  ReadLock r = lock.readLock();  WriteLock w = lock.writeLock(); 两者都有lock,unlock方法。写写,写读互斥;读读不互斥。可以实现并发读的高效线程安全代码4.容器类 这里就讨论比较常用的两个: BlockingQueueConcurrentHashMap BlockingQueue阻塞队列。该类是java.util.concurrent包下的重要类,通过对Queue的学习可以得知,这个queue是单向队列,可以在队列头添加元素和在队尾删除或取出元素。类似于一个管  道,特别适用于先进先出策略的一些应用场景。普通的queue接口主要实现有PriorityQueue(优先队列),有兴趣可以研究 BlockingQueue在队列的基础上添加了多线程协作的功能: BlockingQueue 除了传统的queue功能(表格左边的两列)之外,还提供了阻塞接口put和take,带超时功能的阻塞接口offer和poll。put会在队列满的时候阻塞,直到有空间时被唤醒;take在队 列空的时候阻塞,直到有东西拿的时候才被唤醒。用于生产者-消费者模型尤其好用,堪称神器。 常见的阻塞队列有: ArrayListBlockingQueueLinkedListBlockingQueueDelayQueueSynchronousQueue ConcurrentHashMap高效的线程安全哈希map。请对比hashTable , concurrentHashMap, HashMap5.管理类 管理类的概念比较泛,用于管理线程,本身不是多线程的,但提供了一些机制来利用上述的工具做一些封装。了解到的值得一提的管理类:ThreadPoolExecutor和 JMX框架下的系统级管理类 ThreadMXBeanThreadPoolExecutor如果不了解这个类,应该了解前面提到的ExecutorService,开一个自己的线程池非常方便:复制代码 ExecutorService e = Executors.newCachedThreadPool(); ExecutorService e = Executors.newSingleThreadExecutor(); ExecutorService e = Executors.newFixedThreadPool(3); // 第一种是可变大小线程池,按照任务数来分配线程, // 第二种是单线程池,相当于FixedThreadPool(1) // 第三种是固定大小线程池。 // 然后运行 e.execute(new MyRunnableImpl()); 复制代码 该类内部是通过ThreadPoolExecutor实现的,掌握该类有助于理解线程池的管理,本质上,他们都是ThreadPoolExecutor类的各种实现版本。请参见javadoc: ThreadPoolExecutor参数解释 翻译一下:复制代码 corePoolSize:池内线程初始值与最小值,就算是空闲状态,也会保持该数量线程。maximumPoolSize:线程最大值,线程的增长始终不会超过该值。keepAliveTime:当池内线程数高于corePoolSize时,经过多少时间多余的空闲线程才会被回收。回收前处于wait状态unit:时间单位,可以使用TimeUnit的实例,如TimeUnit.MILLISECONDS workQueue:待入任务(Runnable)的等待场所,该参数主要影响调度策略,如公平与否,是否产生饿死(starving)threadFactory:线程工厂类,有默认实现,如果有自定义的需要则需要自己实现ThreadFactory接口并作为参数传入。 阿里云优惠券地址https://promotion.aliyun.com/ntms/yunparter/invite.html?userCode=nb3paa5b

景凌凯 2019-12-02 01:40:35 0 浏览量 回答数 0

问题

创建及配置集群

反向一觉 2019-12-01 21:07:21 1249 浏览量 回答数 0

问题

quickdb 另辟捷径高效解决NOSQL数据库 数据持久性问题:报错

kun坤 2020-06-07 16:39:10 0 浏览量 回答数 1

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

《公交线路客流预测》攻略-附平台mr示例代码

楠兮 2019-12-01 21:31:10 16683 浏览量 回答数 5

问题

点晴模切ERP软件对模切行业管理的影响

clicksun 2019-12-01 20:11:17 1792 浏览量 回答数 2

问题

HBase查询优化

pandacats 2019-12-20 21:09:28 0 浏览量 回答数 0

问题

【云服务器分享】简述云服务器对比VPS

dreamdoo 2019-12-01 20:28:31 114107 浏览量 回答数 33

问题

【今日算法】4月23日-如何调度考生的座位

游客ih62co2qqq5ww 2020-04-23 20:33:10 19 浏览量 回答数 1

回答

转自:阿飞的博客 一、数据库技术选型的思考维度 我们做选型的时候首先要问: 谁选型?是负责采购的同学、 DBA 还是业务研发? 如果选型的是采购的同学,他们更注重成本,包括存储方式、网络需求等。 如果选型的是 DBA 同学,他们关心的: ① 运维成本 首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等; ② 稳定性 其次,DBA会关注稳定性,包括是否支持数据多副本、服务高可用、多写多活等; ③ 性能 第三是性能,包括延迟、QPS 以及是否支持更高级的分级存储功能等; ④ 拓展性 第四是扩展性,如果业务的需求不确定,是否容易横向扩展和纵向扩容; ⑤ 安全 最后是安全,需要符合审计要求,不容易出现 SQL 注入或拖库情况。 ⑥ 其他 除了采购和 DBA之外,后台应用研发的同学同样会关注稳定性、性能、扩展性等问题,同时也非常关注数据库接口是否便于开发,是否便于修改数据库 schema 等问题。 接下来我们来看一下爱奇艺使用的数据库类型: MySQL,互联网业务必备系统; TiDB,爱奇艺的 TiDB 实践会有另外的具体介绍; Redis,KV 数据库,互联网公司标配; Couchbase,这个在爱奇艺用得比较多,但国内互联网公司用得比较少,接下来的部分会详细说明; 其他,比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等; 大数据分析相关系统,比如 Hive、Impala 等等。 可以看到爱奇艺的数据库种类还是很多的,这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。 那么,我们先对这些数据库按照接口(SQL、NoSQL)和面向的业务场景(OLTP、OLAP)这两位维度进行一个简单非严谨的分类。 下图中,左上角是面向 OLTP、支持 SQL 的这样一类系统,例如 MySQL,一般支持事务不同的隔离级别, QPS 要求比较高,延时比较低,主要用于交易信息和关键数据的存储,比如订单、VIP 信息等。 左下角是 NoSQL 数据库,是一类针对特殊场景做优化的系统,schema 一般比较简单,吞吐量较高、延迟较低,一般用作缓存或者 KV 数据库。 整个右侧都是 OLAP 的大数据分析系统,包括 Clickhouse、Impala等,一般支持SQL、不支持事务,扩展性比较好,可以通过加机器增加数据的存储量,响应延迟较长。 还有一类数据库是比较中立的,在数据量比较小的时候性能比较好,在数据量较大或复杂查询的时候性能也不差,一般通过不同的存储引擎和查询引擎来满足不同的业务需求,我们把它叫做 HTAP,TiDB 就是这样一种数据库。 二、iQIYI对数据库的优化与完善 前面我们提到了很多种的数据库,那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。 1、MySQL在爱奇艺的使用 ① MySQL 首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步,支持每周全备+每日增量备份。我们做了一些基本功能的增强,首先是增强了数据恢复工具 Xtrabackup 的性能。 之前遇到一个情况,我们有一个全量库是 300G 数据,增量库每天 70G 数据,总数据量 700G 左右。我们当时只需要恢复一个表的数据,但该工具不支持单表恢复,且整库恢复需要 5 个小时。 针对这个情况我们具体排查了原因,发现在数据恢复的过程中需要进行多次写盘的 IO 操作并且有很多串行操作,所以我们做了一些优化。例如删减过程中的一些写盘操作,减少落盘并将数据处理并行化,优化后整库恢复耗时减少到 100 分钟,而且可以直接恢复单表数据。 然后是适配 DDL 和 DML 工具到内部系统,gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时,所以我们在使用工具的时候也增加了延时上的考虑,实时探测Master-Slave 库之间延时的情况,如果延时较大会暂停工具的使用,恢复到正常水平再继续。 ② MySQL高可用 第二是 MySQL 高可用。Master-slave 加上半同步这种高可用方式不太完善,所以我们参照了 MHA 并进行了改动,采用 master + agent 的方式。Agent 在每一个物理机上部署,可以监控这个物理机上的所有实例的状态,周期性地向 master 发送心跳,Master 会实时监测各个Agent的状态。 如果 MySQL故障,会启动 Binlog 补偿机制,并切换访问域名完成 failover。考虑到数据库跨机房跨地区部署的情况,MHA 的 master 我们也做了高可用设计,众多 master 会通过 raft 组成一个 raft group,类似 TiDB 的 PD 模块。目前 MySQL failover 策略支持三种方式:同机房、同地域跨机房以及跨地域。 ③ MySQL拓展能力 第三是提高MySQL扩展能力,以提供更大容量的数据存储。扩展方式有 SDK,例如开源的 ShardingSphere,在爱奇艺的使用也比较广泛。另外就是 Proxy,开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单,扩容难度大,依赖较多且运维复杂,所以部分业务已经迁移至 TiDB。 ④ 审计 第四是审计。我们在 MySQL 上做了一个插件获取全量 SQL 操作,后端打到 Kafka,下游再接入包括 Clickhouse 等目标端进行 SQL 统计分析。除此之外还有安全策略,包括主动探索是否有 SQL 注入及是否存在拖库情况等,并触发对应的告警。 MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响,对此我们进行了一些测试,发现使用 General Log 对性能损耗较大,有 10%~20% 的降低。 于是我们通过接口来获取 MySQL 插件里的监控项,再把监控项放到 buffer 里边,用两级的 RingBuffer 来保证数据的写入不会有锁资源竞争。在这个插件里再启动一个线程,从 RingBuffer 里读取数据并把数据打包写到 FIFO 管道里。 我们在每台 MySQL 的物理机里再启动一个 Agent,从管道里阻塞地读取数据发至 Kafka。优化后我们再次进行压测,在每台机器上有 15 万的更新、删除或插入操作下不会丢失数据,性能损耗一般情况下小于 2%。 目前已经在公司内部的集群上线了一年时间,运行比较稳定,上线和下线对业务没有影响。 ⑤ 分级存储 第五是分级存储。MySQL 里会存一些过程性的数据,即只需要读写最近一段时间存入的数据,过段时间这些数据就不需要了,需要进行定时清理。 分级存储就是在 MySQL 之上又用了其他存储方式,例如 TiDB 或其他 TokuDB,两者之间可以进行数据自动搬迁和自动归档,同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来,业务的开发同学只需要将数据存入 MySQL 里,读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用,之后会根据 TiDB 的特性进行逐步迁移。 Redis在爱奇艺的使用 接下来是 Redis。Redis 也是使用 master - slave 这种方式,由于网络的复杂性我们对 Sentinel 的部署进行了一些特殊配置,在多机房的情况下每个机房配置一定数量 Sentinel 来避免脑裂。 备份恢复方面介绍一个我们的特殊场景,虽然 Redis 是一个缓存,但我们发现不少的业务同学会把它当做一个 KVDB 来使用,在某些情况下会造成数据的丢失。 所以我们做了一个 Redis 实时备份功能,启动一个进程伪装成 Redis 的 Slave 实时获取数据,再放到后端的 KV 存储里,例如 ScyllaDB,如果要恢复就可以从 ScyllaDB 里把数据拉出来。 我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时,会由 Sentinel 重新选出一个新的节点成为 Master,再把该节点上的数据同步到所有 Slave 上,此过程中数据会放在 Master 节点的 Buffer 里,如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去,重建过程就会失败。 基于这种情况,我们对 Redis 告警做了自动化优化,如有大量 master - slave 重建失败,我们会动态调整一些参数,例如把 Buffer 临时调大等, 此外我们还做了 Redis 集群的自动扩缩容功能。 我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群,如果某个分片发生了故障或者 failover,Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题,整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis,如果某个分片发生故障,就只针对这个分片进行重建。 在业务访问 Redis 时我们会对 Master 绑定一个读写域名,多个从库绑定读域名。但如果我们进行 Master failover,会将读写域名从某旧 Master 解绑,再绑定到新 Master 节点上。 DNS 本身有一个超时时间,所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话,有可能还会连到原来的机器上,造成访问失败。 我们的解决方法是把 DNS 的 TTL 缩短,但对 DNS 服务又会造成很大的压力,所以我们在 SDK 上提供 Redis 的名字服务 RNS,RNS 从 Sentinel 里获取集群的拓扑和拓扑的变化情况,如果集群 failover,Sentinel 会接到通知,客户端就可以通过 RNS 来获取新的 Master 节点的 IP 地址。我们去掉域名,通过 IP 地址来访问整个集群,屏蔽了 DNS 的超时,缩短了故障的恢复时间。 SDK 上还做了一些功能,例如 Load Balance 以及故障检测,比如某个节点延时较高的话会被临时熔断等。 客户端分片的方式会造成 Redis 的扩容非常痛苦,如果客户端已经进行了一定量的分片,之后再增加就会非常艰难。 Redis 在 3.0 版本后会提供 Redis Cluster,因为功能受限在爱奇艺应用的不是很多,例如不支持显示跨 DC 部署和访问,读写只在主库上等。 我们某些业务场景下会使用 Redis 集群,例如数据库访问只发生在本 DC,我们会在 DC 内部进行 Cluster 部署。 但有些业务在使用的过程中还是想做 failover,如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy,读写都通过它来进行。写入数据时 Proxy 会做一个旁路,把新增的数据写在 Kafka 里,后台启用同步程序再把 Kafka 里的数据同步到其他集群,但存在一些限制,比如我们没有做冲突检测,所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。 2、Couchbase在爱奇艺的使用 Redis 虽然提供 Cluster 这种部署方式,但存在一些问题。所以数据量较大的时候(经验是 160G),就不推荐 Redis 了,而是采用另一种存储方式 Couchbase。 Couchbase 在国内互联网公司用的比较少,一开始我们是把他当做一个 Memcached 来使用的,即纯粹的缓存系统。 但其实它性能还是比较强大的,是一个分布式高性能的 KV 系统,支持多种存储引擎 (bucket)。第一种是 Memcached bucket,使用方式和 Memcached 一样为 KV 存储,不支持数据持久化也没有数据副本,如果节点故障会丢失数据; 第二种是 Couchbase bucket,支持数据持久化,使用 Json 写入,有副本,我们一般会在线上配置两个副本,如果新加节点会对数据进行 rebalance,爱奇艺使用的一般是 Couchbase bucket 这种配置。 Couchbase 数据的分布如下图,数据写入时在客户端上会先进行一次哈希运算,运算完后会定位 Key 在哪一个 vBucket (相当于数据库里的某个分片)。之后客户端会根据 Cluster Map 发送信息至对应的服务端,客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系,在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新,因此客户端对于服务端的 failover 操作不需要做特殊处理,但可能在 rebalance 过程中会有短暂的超时,导致的告警对业务影响不大。 Couchbase 在爱奇艺应用比较早,2012 年还没有 Redis Cluster 的时候就开始使用了。集群管理使用 erlang 语言开发,最大功能是进行集群间的复制,提供多种复制方式:单向、双向、星型、环式、链式等。 爱奇艺从最初的 1.8 版本使用到如今的 5.0 版本,正在调研的 6.0,中间也遇到了很多坑,例如 NTP 时间配置出错会导致崩溃,如果每个集群对外 XDCR 并发过高导致不稳定,同步方向变更会导致数据丢失等等,我们通过运维和一些外部工具来进行规避。 Couchbase 的集群是独立集群,集群间的数据同步通过 XDCR,我们一般配置为双向同步。对于业务来说,如果 Cluster 1 写入, Cluster 2 不写入,正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障,我们提供了一个 Java SDK,可以在配置中心把写入更改到 Cluster 2,把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。 3、爱奇艺自研数据库HiKV的使用 Couchbase 虽然性能非常高,并且数据的存储可以超过内存。但是,如果数据量超过内存 75% 这个阈值,性能就会下降地特别快。在爱奇艺,我们会把数据量控制在可用内存的范围之内,当做内存数据库使用。但是它的成本非常高,所以我们后面又开发了一个新的数据库—— HiKV。 开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB,主要使用了其分布式数据库的管理功能,增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍,又完全兼容 Cassandra 接口,设计基本一致,可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架,例如 C++ 异步框架 seastar,主要原理是在j每台物理机的核上会 attach 一个应用线程,每个核上有自己独立的内存、网络、IO 资源,核与核之间没有数据共享但可以通信,其最大的好处是内存访问无锁,没有冲突过程。 当一个数据读或写到达 ScyllaDB 的 server 时,会按照哈希算法来判断请求的 Key 是否是该线程需要处理的,如果是则本线程处理,否则会转发到对应线程上去。 除此之外,它还支持多副本、多数据中心、多写多活,功能比较强大。 在爱奇艺,我们基于 SSD 做了一个 KV 存储引擎。Key 放在内存里,Value 放在盘上的文件里,我们在读和写文件时,只需要在内存索引里定位,再进行一次盘的 IO 开销就可以把数据读出来,相比 ScyllaDB 原本基于 LSM Tree 的存储引擎方式对 IO 的开销较少。 索引数据全部放在内存中,如果索引长度较长会限制单机可存储的数据量,于是我们通过开发定长的内存分布器,对于比较长的 Key 做摘要缩短长度至 20 字节,采用红黑树索引,限制每条记录在内存里的索引长度至为 64 字节。内存数据要定期做 checkpoint,客户端要做限流、熔断等。 HiKV 目前在爱奇艺应用范围比较大,截至目前已经替换了 30% 的 Couchbase,有效地降低了存储成本。 4、爱奇艺的数据库运维管理 爱奇艺数据库种类较多,如何高效地运维和管理这些数据库也是经历了不同的阶段。 最初我们通过 DBA 写脚本的方式管理,如果脚本出问题就找 DBA,导致了 DBA 特别忙碌。 第二个阶段我们考虑让大家自己去查问题的答案,于是在内部构建了一个私有云,通过 Web 的方式展示数据库运行状态,让业务的同学可以自己去申请集群,一些简单的操作也可以通过自服务平台实现,解放了 DBA。一些需要人工处理的大型运维操作经常会造成一些人为故障,敲错参数造成数据丢失等。 于是在第三个阶段我们把运维操作 Web 化,通过网页点击可以进行 90% 的操作。 第四个阶段让经验丰富的 DBA 把自身经验变成一些工具,比如有业务同学说 MySQL master-slave 延时了,DBA 会通过一系列操作排查问题。现在我们把这些操作串起来形成一套工具,出问题时业务的同学可以自己通过网页上的一键诊断工具去排查,自助进行处理。 除此之外我们还会定期做预警检查,对业务集群里潜在的问题进行预警报告;开发智能客服,回答问题;通过监控的数据对实例打标签,进行削峰填谷地智能调度,提高资源利用率。 三、不同场景下数据库选型建议 1、实用数据库选型树 最后来说一些具体数据库选型建议。这是 DBA 和业务一起,通过经验得出来的一些结论。 对于关系型数据库的选型来说,可以从数据量和扩展性两个维度考虑,再根据数据库有没有冷备、要不要使用 Toku 存储引擎,要不要使用 Proxy 等等进行抉择。 NoSQL 也是什么情况下使用 master-slave,什么情况下使用客户端分片、集群、Couchbase、HiKV 等,我们内部自服务平台上都有这个选型树信息。 2、一些思考 ① 需求 我们在选型时先思考需求,判断需求是否真实。 你可以从数据量、QPS、延时等方面考虑需求,但这些都是真实需求吗?是否可以通过其他方式把这个需求消耗掉,例如在数据量大的情况下可以先做数据编码或者压缩,数据量可能就降下来了。 不要把所有需求都推到数据库层面,它其实是一个兜底的系统。 ② 选择 第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么?是因为热门吗?还是因为技术上比较先进?但是不是能真正地解决你的问题?如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。 ③ 放弃 第三是放弃,当你放弃一个系统时真的是因为不好用吗?还是没有用好?放弃一个东西很难,但在放弃时最好有一个充分的理由,包括实测的结果。 ④ 自研 第四是自研,在需要自己开发数据库时可以参考和使用一些成熟的产品,但不要盲目自研。 ⑤ 开源 最后是开源,要有拥抱开源的态度。

茶什i 2019-12-27 14:17:56 0 浏览量 回答数 0

问题

点晴模切ERP软件对模切行业管理的影响

clicksun 2019-12-01 21:58:54 2521 浏览量 回答数 1

回答

提出此问题已有7年了,似乎仍然没有人提出这个问题的好的解决方案。Repa没有类似mapM/的traverse功能,即使没有并行也可以运行。而且,考虑到过去几年中取得的进步,似乎也不大可能实现。 由于Haskell中许多数组库的状态过时,以及我对其功能集的总体不满,我将几年的工作放在了一个数组库中massiv,该库借鉴了Repa的一些概念,但是将其带到了一个完全不同的水平。介绍足够了。 在此之前的今天,出现了像三种功能一元地图massiv(不包括类似功能的代名词:imapM,forM。等): mapM-任意映射中的通常映射Monad。由于明显的原因,不可并行化,并且速度也较慢(沿mapM列表中的常规行速度较慢) traversePrim-在这里,我们被限制为PrimMonad,其速度明显快于mapM,但是这样做的原因在本次讨论中并不重要。 mapIO-顾名思义,该名称仅限于IO(或更确切地说MonadUnliftIO,但这无关紧要)。因为我们在其中,所以IO我们可以自动将数组拆分为与内核一样多的块,并使用单独的工作线程IO在这些块中的每个元素上映射操作。与pure fmap也可以并行化不同,IO由于调度的不确定性以及映射操作的副作用,我们必须处于此状态。 因此,一旦我阅读了这个问题,我就以为自己可以在中解决该问题massiv,但速度并没有那么快。in mwc-random和in中的随机数生成器random-fu不能在多个线程中使用同一生成器。这意味着,我唯一缺少的难题是:“为产生的每个线程绘制一个新的随机种子,并像往常一样进行”。换句话说,我需要两件事: 该函数将初始化与工作线程数量一样多的生成器 以及一个抽象,它将根据动作在哪个线程中无缝地为映射函数提供正确的生成器。 这正是我所做的。 首先,我将使用特制的randomArrayWS和initWorkerStates函数给出示例,因为它们与问题更相关,然后再转到更通用的单子图。这是它们的类型签名: randomArrayWS :: (Mutable r ix e, MonadUnliftIO m, PrimMonad m) => WorkerStates g -- ^ Use initWorkerStates to initialize you per thread generators -> Sz ix -- ^ Resulting size of the array -> (g -> m e) -- ^ Generate the value using the per thread generator. -> m (Array r ix e) initWorkerStates :: MonadIO m => Comp -> (WorkerId -> m s) -> m (WorkerStates s) 对于不熟悉的人massiv,该Comp参数是要使用的计算策略,值得注意的构造函数是: Seq -按顺序运行计算,无需派生任何线程 Par -旋转尽可能多的线程,并使用它们来完成工作。 mwc-random最初,我将使用package作为示例,然后转到RVarT: λ> import Data.Massiv.Array λ> import System.Random.MWC (createSystemRandom, uniformR) λ> import System.Random.MWC.Distributions (standard) λ> gens <- initWorkerStates Par (_ -> createSystemRandom) 上面我们使用系统随机性为每个线程初始化了一个单独的生成器,但是我们也可以通过从WorkerId参数(仅Int是worker的索引)派生每个线程种子来使用唯一的种子。现在我们可以使用这些生成器来创建具有随机值的数组: λ> randomArrayWS gens (Sz2 2 3) standard :: IO (Array P Ix2 Double) Array P Par (Sz (2 :. 3)) [ [ -0.9066144845415213, 0.5264323240310042, -1.320943607597422 ] , [ -0.6837929005619592, -0.3041255565826211, 6.53353089112833e-2 ] ] 通过使用Par策略,scheduler库会将生成工作平均分配给可用的工作程序,每个工作程序将使用其自己的生成器,从而使其线程安全。WorkerStates只要没有同时执行,什么都不会阻止我们重复使用相同的任意次数,否则将导致异常: λ> randomArrayWS gens (Sz1 10) (uniformR (0, 9)) :: IO (Array P Ix1 Int) Array P Par (Sz1 10) [ 3, 6, 1, 2, 1, 7, 6, 0, 8, 8 ] 现在mwc-random,我们可以通过使用类似的功能将相同的概念重用于其他可能的用例generateArrayWS: generateArrayWS :: (Mutable r ix e, MonadUnliftIO m, PrimMonad m) => WorkerStates s -> Sz ix -- ^ size of new array -> (ix -> s -> m e) -- ^ element generating action -> m (Array r ix e) 和mapWS: mapWS :: (Source r' ix a, Mutable r ix b, MonadUnliftIO m, PrimMonad m) => WorkerStates s -> (a -> s -> m b) -- ^ Mapping action -> Array r' ix a -- ^ Source array -> m (Array r ix b) 下面是关于如何使用这个功能所承诺的例子rvar,random-fu和mersenne-random-pure64图书馆。我们也可以在randomArrayWS这里使用,但是为了举例说明,我们已经有一个带有不同RVarTs 的数组,在这种情况下,我们需要一个mapWS: λ> import Data.Massiv.Array λ> import Control.Scheduler (WorkerId(..), initWorkerStates) λ> import Data.IORef λ> import System.Random.Mersenne.Pure64 as MT λ> import Data.RVar as RVar λ> import Data.Random as Fu λ> rvarArray = makeArrayR D Par (Sz2 3 9) (\ (i :. j) -> Fu.uniformT i j) λ> mtState <- initWorkerStates Par (newIORef . MT.pureMT . fromIntegral . getWorkerId) λ> mapWS mtState RVar.runRVarT rvarArray :: IO (Array P Ix2 Int) Array P Par (Sz (3 :. 9)) [ [ 0, 1, 2, 2, 2, 4, 5, 0, 3 ] , [ 1, 1, 1, 2, 3, 2, 6, 6, 2 ] , [ 0, 1, 2, 3, 4, 4, 6, 7, 7 ] ] 重要的是要注意,尽管在上面的示例中使用的是Mersenne Twister的纯实现,但我们无法逃脱IO。这是由于不确定的调度,这意味着我们永远不知道哪个工作人员将处理数组的哪个块,因此哪个生成器将用于数组的哪个部分。从好的方面来说,如果生成器是纯的且可拆分的,例如splitmix,那么我们可以使用纯的,确定性的和可并行化的生成函数:randomArray,但这已经是一个独立的故事了。

保持可爱mmm 2020-02-08 13:30:20 0 浏览量 回答数 0

问题

【今日算法】备战大厂必备题目,持续更新

游客ih62co2qqq5ww 2020-04-08 09:21:40 3542 浏览量 回答数 4

问题

10个迷惑新手的Cocoa,Objective-c开发难点和问题? 400 报错

爱吃鱼的程序员 2020-05-31 00:44:29 0 浏览量 回答数 1

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

回答

X-Engine是阿里云数据库产品事业部自研的联机事务处理OLTP(On-Line Transaction Processing)数据库存储引擎。作为自研数据库POLARDB的存储引擎之一,已经广泛应用在阿里集团内部诸多业务系统中,包括交易历史库、钉钉历史库等核心应用,大幅缩减了业务成本,同时也作为双十一大促的关键数据库技术,挺过了数百倍平时流量的冲击。 为什么设计一个新的存储引擎 X-Engine的诞生是为了应对阿里内部业务的挑战,早在2010年,阿里内部就大规模部署了MySQL数据库,但是业务量的逐年爆炸式增长,数据库面临着极大的挑战: 极高的并发事务处理能力(尤其是双十一的流量突发式暴增)。 超大规模的数据存储。 这两个问题虽然可以通过扩展数据库节点的分布式方案解决,但是堆机器不是一个高效的手段,我们更想用技术的手段将数据库性价比提升到极致,实现以少量资源换取性能大幅提高的目的。 传统数据库架构的性能已经被仔细的研究过,数据库领域的泰斗,图灵奖得主Michael Stonebreaker就此写过一篇论文 《OLTP Through the Looking Glass, and What We Found There》 ,指出传统关系型数据库,仅有不到10%的时间是在做真正有效的数据处理工作,剩下的时间都浪费在其它工作上,例如加锁等待、缓冲管理、日志同步等。 造成这种现象的原因是因为近年来我们所依赖的硬件体系发生了巨大的变化,例如多核(众核)CPU、新的处理器架构(Cache/NUMA)、各种异构计算设备(GPU/FPGA)等,而架构在这些硬件之上的数据库软件却没有太大的改变,例如使用B-Tree索引的固定大小的数据页(Page)、使用ARIES算法的事务处理与数据恢复机制、基于独立锁管理器的并发控制等,这些都是为了慢速磁盘而设计,很难发挥出现有硬件体系应有的性能。 基于以上原因,阿里开发了适合当前硬件体系的存储引擎,即X-Engine。 X-Engine架构 全新架构的X-Engine存储引擎不仅可以无缝对接兼容MySQL(得益于MySQL Pluginable Storage Engine特性),同时X-Engine使用分层存储架构。 因为目标是面向大规模的海量数据存储,提供高并发事务处理能力和降低存储成本,在大部分大数据量场景下,数据被访问的机会是不均等的,访问频繁的热数据实际上占比很少,X-Engine根据数据访问频度的不同将数据划分为多个层次,针对每个层次数据的访问特点,设计对应的存储结构,写入合适的存储设备。 X-Engine使用了LSM-Tree作为分层存储的架构基础,并进行了重新设计: 热数据层和数据更新使用内存存储,通过内存数据库技术(Lock-Free index structure/append only)提高事务处理的性能。 流水线事务处理机制,把事务处理的几个阶段并行起来,极大提升了吞吐。 访问频度低的数据逐渐淘汰或是合并到持久化的存储层次中,并结合多层次的存储设备(NVM/SSD/HDD)进行存储。 对性能影响比较大的Compaction过程做了大量优化: 拆分数据存储粒度,利用数据更新热点较为集中的特征,尽可能的在合并过程中复用数据。 精细化控制LSM的形状,减少I/O和计算代价,有效缓解了合并过程中的空间增大。 同时使用更细粒度的访问控制和缓存机制,优化读的性能。 技术特点 利用FPGA硬件加速Compaction过程,使得系统上限进一步提升。这个技术属首次将硬件加速技术应用到在线事务处理数据库存储引擎中,相关论文 《FPGA-Accelerated Compactions for LSM-based Key Value Store》 已经被2020年的顶级会议FAST'20接收。 通过数据复用技术减少数据合并代价,同时减少缓存淘汰带来的性能抖动。 使用多事务处理队列和流水线处理技术,减少线程上下文切换代价,并计算每个阶段任务量配比,使整个流水线充分流转,极大提升事务处理性能。相对于其他类似架构的存储引擎(例如RocksDB),X-Engine的事务处理性能有10倍以上提升。 X-Engine使用的Copy-on-write技术,避免原地更新数据页,从而对只读数据页面进行编码压缩,相对于传统存储引擎(例如InnoDB),使用X-Engine可以将存储空间降低至10%~50%。 Bloom Filter快速判定数据是否存在,Surf Filter判断范围数据是否存在,Row Cache缓存热点行,加速读取性能。 LSM基本逻辑 LSM的本质是所有写入操作直接以追加的方式写入内存。每次写到一定程度,即冻结为一层(Level),并写入持久化存储。所有写入的行,都以主键(Key)排序好后存放,无论是在内存中,还是持久化存储中。在内存中即为一个排序的内存数据结构(Skiplist、B-Tree、etc),在持久化存储也作为一个只读的全排序持久化存储结构。 普通的存储系统若要支持事务处理,需要加入一个时间维度,为每个事务构造出一个不受并发干扰的独立视域。例如存储引擎会对每个事务定序并赋予一个全局单调递增的事务版本号(SN),每个事务中的记录会存储这个SN以判断独立事务之间的可见性,从而实现事务的隔离机制。 如果LSM存储结构持续写入,不做其他的动作,那么最终会成为如下结构。 这种结构对于写入是非常友好的,只要追加到最新的内存表中即完成,为实现故障恢复,只需记录Redo Log,因为新数据不会覆盖旧版本,追加记录会形成天然的多版本结构。 但是如此累积,冻结的持久化层次越来越多,会对查询会产生不利的影响。例如对同一个key,不同事务提交产生的多版本记录会散落在各个层次中;不同的key也会散落在不同层次中。读操作需要查找各个层并合并才能得到最终结果。 因此LSM引入了Compaction操作解决这个问题,Compaction操作有2种作用: 控制LSM层次形状 一般的LSM形状都是层次越低,数据量越大(倍数关系),目的是为了提升读性能。 通常存储系统的数据访问都有局部性,大量的访问都集中在少部分数据上,这也是缓存系统能有效工作的基本前提。在LSM存储结构中,如果把访问频率高的数据尽可能放在较高的层次上,存放在快速存储设备中(例如NVM、DRAM),而把访问频率低的数据放在较低层次中,存放在廉价慢速存储设备中。这就是X-Engine的冷热分层概念。 合并数据 Compaction操作不断的把相邻层次的数据合并,并写入更低层次。合并的过程实际上是把要合并的相邻两层或多层的数据读出来,按key排序,相同的key如果有多个版本,只保留新的版本(比当前正在执行的活跃事务中最小版本号新),丢掉旧版本数据,然后写入新的层,这个操作非常耗费资源。 合并数据除了考虑冷热分层以外,还需要考虑其他维度,例如数据的更新频率,大量的多版本数据在查询的时候会浪费更多的I/O和CPU,因此需要优先进行合并以减少记录的版本数量。X-Engine综合考虑了各种策略形成自己的Compaction调度机制。 高度优化的LSM X-Engine的memory tables使用了无锁跳表(Locked-free SkipList),并发读写的性能较高。在持久化层如何实现高效,就需要讨论每层的细微结构。 数据组织 X-Engine的每层都划分成固定大小的Extent,存放每个层次中的数据的一个连续片段(Key Range)。为了快速定位Extent,为每层Extents建立了一套索引(Meta Index),所有这些索引,加上所有的memory tables(active/immutable)一起组成了一个元数据树(Metadata Tree),root节点为Metadata Snapshot,这个树结构类似于B-Tree。 X-Engine中除了当前的正在写入的active memory tables以外,其他结构都是只读的,不会被修改。给定某个时间点,例如LSN=1000,上图中的Metadata Snapshot 1引用到的结构即包含了LSN=1000时的所有的数据的快照,因此这个结构被称为Snapshot。 即便是Metadata结构本身,也是一旦生成就不会被修改。所有的读请求都是以Snapshot为入口,这是X-Engine实现Snapshot级别隔离的基础。前文说过随着数据写入,累积数据越多,会执行Compaction操作、冻结memory tables等,这些操作都是用Copy-on-write实现,即每次都将修改产生的结果写入新的Extent,然后生成新的Meta Index结构,最终生成新的Metadata Snapshot。 例如执行一次Compaction操作会生成新的Metadata Snapshot,如下图所示。 可以看到Metadata Snapshot 2相对于Metadata Snapshot 1并没有太多的变化,仅仅修改了发生变更的一些叶子节点和索引节点。 事务处理 得益于LSM的轻量化写机制,写入操作固然是其明显的优势,但是事务处理不只是把更新的数据写入系统那么简单,还要保证ACID(原子性、一致性、隔离性、持久性),涉及到一整套复杂的流程。X-Engine将整个事务处理过程分为两个阶段: 读写阶段 校验事务的冲突(写写冲突、读写冲突),判断事务是否可以执行、回滚重试或者等锁。如果事务冲突校验通过,则把修改的所有数据写入Transaction Buffer。 提交阶段 写WAL、写内存表,以及提交并返回用户结果,这里面既有I/O操作(写日志、返回消息),也有CPU操作(拷贝日志、写内存表)。 为了提高事务处理吞吐,系统内会有大量事务并发执行,单个I/O操作比较昂贵,大部分存储引擎会倾向于聚集一批事务一起提交,称为Group Commit,能够合并I/O操作。但是一组事务提交的过程中,还是有大量等待过程的,例如写入日志到磁盘过程中,除了等待落盘无所事事。 X-Engine为了进一步提升事务处理的吞吐,使用流水线技术,把提交阶段分为4个独立的更精细的阶段: 拷贝日志到缓冲区(Log Buffer) 日志落盘(Log Flush) 写内存表(Write memory table) 提交返回(Commit) 事务到了提交阶段,可以自由选择执行流水线中任意一个阶段,只要流水线任务的大小划分得当,就能充分并行起来,流水线处于接近满载状态。另外这里利用的是事务处理的线程,而非后台线程,每个线程在执行的时候,选择流水线中的一个阶段执行任务,或者空闲后处理其他请求,没有等待,也无需切换,充分利用了每个线程的能力。 读操作 LSM处理多版本数据的方式是新版本数据记录会追加在老版本数据后面,从物理上看,一条记录不同的版本可能存放在不同的层,在查询的时候需要找到合适的版本(根据事务隔离级别定义的可见性规则),一般查询都是查找最新的数据,总是由最高的层次往低层次找。 对于单条记录的查找而言,一旦找到便可以终止,如果记录在比较高的层次,例如memory tables,很快便可以返回;如果记录已经落入了很低的层次,那就得逐层查找,也许Bloom Filter可以跳过某些层次加快这个旅程,但毕竟还是有很多的I/O操作。X-Engine针对单记录查询引入了Row Cache,在所有持久化的层次的数据之上做了一个缓存,在memory tables中没有命中的单行查询,在Row Cache之中也会被捕获。Row Cache需要保证缓存了所有持久化层次中最新版本的记录,而这个记录是可能发生变化的,例如每次flush将只读的memory tables写入持久化层次时,就需要恰当的更新Row Cache中的缓存记录,这个操作比较微妙,需要精心的设计。 对于范围扫描而言,因为没法确定一个范围的key在哪个层次中有数据,只能扫描所有的层次做合并之后才能返回最终的结果。X-Engine采用了一系列的手段,例如SuRF(SIGMOD'18 best paper)提供range scan filter减少扫描层数、异步I/O与预取。 读操作中最核心的是缓存设计,Row Cache负责单行查询,Block Cache负责Row Cache的漏网之鱼,也用来进行范围扫描。由于LSM的Compaction操作会一次更新大量的Data Block,导致Block Cache中大量数据短时间内失效,导致性能的急剧抖动,因此X-Engine做了很多的优化: 减少Compaction的粒度。 减少Compaction过程中改动的数据。 Compaction过程中针对已有的缓存数据做定点更新。 Compaction Compaction操作是比较重要的,需要把相邻层次交叉的Key Range数据读取合并,然后写到新的位置。这是为前面简单的写入操作付出的代价。X-Engine为优化这个操作重新设计了存储结构。 如前文所述,X-Engine将每一层的数据划分为固定大小的Extent,一个Extent相当于一个小而完整的排序字符串表(SSTable),存储了一个层次中的一个连续片段,连续片段又进一步划分为一个个连续的更小的片段Data Block,相当于传统数据库中的Page,只不过Data Block是只读而且不定长的。 回看并对比Metadata Snapshot 1和Metadata Snapshot 2,可以发现Extent的设计意图。每次修改只需要修改少部分有交叠的数据,以及涉及到的Meta Index节点。两个Metadata Snapshot结构实际上共用了大量的数据结构,这被称为数据复用技术(Data Reuse),而Extent大小正是影响数据复用率的关键,Extent作为一个完整的被复用的物理结构,需要尽可能的小,这样与其他Extent数据交叉点会变少,但又不能非常小,否则需要索引过多,管理成本太大。 X-Engine中Compaction的数据复用是非常彻底的,假设选取两个相邻层次(Level1, Level2)中的交叉的Key Range所涵盖的Extents进行合并,合并算法会逐行进行扫描,只要发现任意的物理结构(包括Data Block和Extent)与其他层中的数据没有交叠,则可以进行复用。只不过Extent的复用可以修改Meta Index,而Data Block的复用只能拷贝,即便如此也可以节省大量的CPU。 一个典型的数据复用在Compaction中的过程可以参考下图。 可以看出数据复用的过程是在逐行迭代的过程中完成的,不过这种精细的数据复用带来另一个副作用,即数据的碎片化,所以在实际操作的过程中也需要根据实际情况进行分析。 数据复用不仅给Compaction操作本身带来好处,降低操作过程中的I/O与CPU消耗,更对系统的综合性能产生一系列的影响。例如c、Compaction过程中数据不用完全重写,大大降低了写入时空间的增大;大部分数据保持原样,数据缓存不会因为数据更新而失效,减少合并过程中因缓存失效带来的读性能抖动。 实际上,优化Compaction的过程只是X-Engine工作的一部分,更重要的是优化Compaction调度的策略,选什么样的Extent、定义compaction任务的粒度、执行的优先级等,都会对整个系统性能产生影响,可惜并不存在什么完美的策略,X-Engine积累了一些经验,定义了很多规则,而探索更合理的调度策略是未来一个重要方向。 适用场景 请参见X-Engine最佳实践。 如何使用X-Engine 请参见使用X-Engine引擎。 后续发展 作为MySQL的存储引擎,持续地提升MySQL系统的兼容能力是一个重要目标,后续会根据需求的迫切程度逐步加强原本取消的一些功能,例如外键,以及对一些数据结构、索引类型的支持。 X-Engine作为存储引擎,核心的价值还在于性价比,持续提升性能降低成本,是一个长期的根本目标,X-Engine还在Compaction调度、缓存管理与优化、数据压缩、事务处理等方向上进行深层次的探索。 X-Engine不仅仅局限为一个单机的数据库存储引擎,未来还将作为自研分布式数据库POLARDB分布式版本的核心,提供企业级数据库服务。

游客yl2rjx5yxwcam 2020-03-08 13:24:40 0 浏览量 回答数 0

回答

怎么 没人来呀 @中山野鬼###### 1、如果想去掉while(true),可以考虑通知实现; 2、关于自动重连的问题,可以考虑重发送逻辑中抽离出来,采用心跳检测完成; 3、另外发送速率统计部分也应该抽离出来。 4、上多通道要考虑资源使用可控。 5、实在不行按照业务拆分成多模块,用redis 或mq类的扩展一下架构设计; ######回复 @OS小小小 : map =(Map)JSONObject.parse(SendMsgCMPP2ThredPoolByDB.ZhangYi.take()); 换成take,阻塞线程,试试。######回复 @OS小小小 : 1、通知只是告知队列里有新的数据需要处理了; 5、内存队列换成redis队列 实现成本增加,但是可扩展性增加;######1、通知实现的话 ,岂不是 无法保证 最少发送么,又会陷入另一个问题中 是吗? 或者是我的想法不对么? 2、嗯,这一块可以这样做。谢谢你 3、速率统计这里 我目前想不到怎么抽离、既可以控制到位,又可以保证不影响。。。 5、redis 是有的 但是 redis的队列的话 跟我这个 没啥区别吧,可能速度更快一点。######while(true) 里面 没数据最起码要休眠啊,不停死循环操作,又没有休眠cpu不高才怪######回复 @OS小小小 : 休眠是必须的,只是前面有数据进来,可以用wait notify 的思路通知,思路就是这样,CountDownLatch 之类多线程通讯也可以实现有数据来就能立即处理的功能######嗯,目前在测试 排除没有数据的情况,所以这一块没有去让他休眠,后面会加进去。 就针对于目前这种情况,有啥好办法吗###### 我的思路是:一个主线程,多个任务子线程。 主线程有一层while(true),这个循环是不断的扫描LinkedBlockingQueue是否有数据,有则交个任务子线程(也就是你这里定义的线程池)处理,而不是像你这样每个子任务线程都有一个while(true) ######这才是对的做法######嗯,这思路可以。谢谢哈###### 引用来自“K袁”的评论 我的思路是:一个主线程,多个任务子线程。 主线程有一层while(true),这个循环是不断的扫描LinkedBlockingQueue是否有数据,有则交个任务子线程(也就是你这里定义的线程池)处理,而不是像你这样每个子任务线程都有一个while(true) 正确做法. 还有就是 LinkedBlockingQueue 本身阻塞的,while(true)没问题,主要在于不需要每个发送线程都去block######while(true)不加休眠就会这样###### java 的线程数量大致要和cpu数量一致,并不是越多越快,线程调度是很消耗时间的。要用好多线程,就需要设计出好的多线程业务模型,不恰当的sleep和block是性能的噩梦。利用好LinkedBlockingQueue,队列空闲时读队列的线程会释放cpu。利用消息触发后续线程工作,就没必要使用while(true)来不停的扫描。 ######@蓝水晶飞机 看到你要比牛逼,我就没有兴趣跟你说话了######回复 @不日小鸡 : 我就是装逼怎么啦,特么的装逼装出样子来的,起码也比你牛逼啊。######回复 @蓝水晶飞机 : 你说这话不能掩盖你没有回复我的问题又来回复我导致装逼失败的事实。 那你不是楼主你回复我干什么,还不是回答我的问题。 不要装逼了好么,装多就成傻逼了######回复 @不日小鸡 : 此贴楼主不是你,装什么逼。######回复 @王斌_ : 这些我都知道,我的意思是你这样回复可能会误导其他看帖子的人或者新手,让他们以为线程数就等于CPU数###### 引用来自“OS小小小”的评论 怎么 没人来呀 @中山野鬼 抬举我了。c++ 我还敢对不知深浅的人说,“权当我不懂”,java真心只是学过,没有实际工程上的经验。哈。而且我是c的思维,面对c适合的应用开发,是反对使用线程的。基本思维是,执行模块的生命周期不以任务为决定,同类的执行模块,可根据物理硬核数量,形成对应独立多个进程,但绝对不会同类的任务独立对应多个线程。哈。所以java这类面向线程的设计,没办法参与讨论。设计应用目标不同,系统组织策略自然有异。 唯一的建议是:永远不要依赖工具,特别是所谓的垃圾资源处理回收机制,无论它做的再好,一旦你依赖,必然你的代码,在不久的将来会因为系统设计规模的变大,而变的垃圾。哈。 听不懂的随便喷,希望听懂的,能记得这个观点,这不是我一个人的观点。 ######给100万像素做插值运算进行染色特效,请问单线程怎么做比多线程快?###### @乌龟壳 : 几种方法都可以,第一是按照计算步骤,每个进程处理一个步骤,然后切换共享空间(这没有数据传递逻辑上的额外开销),就是流水思维。第二个是block的思维,同样的几个进程负责相同计算,但负责不同片区。同时存在另一类的进程是对前期并发处理完的工作进行边界处理。 你这个例子体现不出进程和线程的差异的。 如果非要考虑进程和线程在片内cache的差异,如果没记错(错了大家纠正哈),进程之间的共享是在二级缓存之间吧。即便线程能做到一级缓存之间的共享,但对于这种大批量像素的计算,用进程仍然是使用 dma,将数据成块载入一级缓存区域进行处理,而这个载入工作和计算工作是同步的。不会有额外太多的延迟。 你举的这个例子,还真好是我以前的老本行。再说了。像素计算,如今都用专用计算处理器了吧。还用x86或arm来处理,不累死啊。哈。 而且这种东西java不适合,同样的处理器,用c写,基本可以比java快1到2倍。因为c可以直接根据硬件特性和计算逻辑特点有效调度底层硬件驱动方式。而java即便你用了底层优化的官方库,仍然不能保证硬件与计算目标特性的高度整合。 ######回复 @中山野鬼 : 简单来说,你的多个进程处理结果进行汇总的时候,是不是要做内存复制操作?如果是多线程天然就不用,多进程用系统的共享内存机制也不用,问题是既然用了共享内存,和多线程就没区别了。######回复 @乌龟壳 : 两回事哦。共享空间是独立的,而线程如果我没记错,全局变量,包括文件内的(静态变量)是共享的。不同线程共享同一个进程内的变量嘛。这些和业务逻辑相关的东西,每个线程又是独立一套业务逻辑,针对c语言,这样去设计,不是没事找事嘛。面向对象语言,这块都帮你处理好了,自然没有关系。######既然有共享空间了,那你所说的进程和线程实际就是一回事了。###### @乌龟壳   ,数据分两种,一种和算法或处理相关的。一种是待处理的数据。 前者,不应该共享,后者属于数据加工流程,必然存在数据传递或流动,最低成本的传递/流动方式就是共享内存,交替使用权限的思路。 但这仅仅针对待加工的数据和辅助信息,而不针对程序本身。 进程不会搞混乱这些东西特别是(待加工数据的辅助信息),而线程,就各种乱吧。哈。 进程之间,虽然用共享空间,但它本质是数据传递/流动,当你采用多机(物理机器)并发处理时,进程移动到另外一个物理主机,则共享空间就是不能选择的传递/流动方式了。但线程就没有这些概念。 ######回复 @中山野鬼 : 是啊,java天然就不是像C一样对汇编的包装。######@乌龟壳 面向企业级的各种业务,java这些没问题的。而且更有优势,面向计算设备特性的设计开发,就不行了。哈。######回复 @中山野鬼 : 也算各有场景吧,java同样可以多进程可以分布式来降低多线程的风险。java也可以静态编译成目标机器码。总之事在人为。######回复 @乌龟壳 : 高手,啥都可以,低手,依赖这些,就是各种想当然。哈哈。######回复 @中山野鬼 : 那针对java的垃圾回收,这个东西是可以调节它算法的,不算依赖工具吧,哈。不然依赖C语言语法也算依赖工具咯。哈。;-p

kun坤 2020-05-31 13:04:51 0 浏览量 回答数 0

回答

同步两个SQLServer数据库 如何同步两个sqlserver数据库的内容?程序代码可以有版本管理cvs进行同步管理,可是数据库同步就非常麻烦,只能自己改了一个后再去改另一个,如果忘记了更改另一个经常造成两个数据库的结构或内容上不一致.各位有什么好的方法吗? 一、分发与复制 用强制订阅实现数据库同步操作. 大量和批量的数据可以用数据库的同步机制处理: // 说明: 为方便操作,所有操作均在发布服务器(分发服务器)上操作,并使用推模式 在客户机器使用强制订阅方式。 二、测试通过 1:环境 服务器环境: 机器名称: zehuadb 操作系统:windows 2000 server 数据库版本:sql 2000 server 个人版 客户端 机器名称:zlp 操作系统:windows 2000 server 数据库版本:sql 2000 server 个人版 2:建用户帐号 在服务器端建立域用户帐号 我的电脑管理->本地用户和组->用户->建立 username:zlp userpwd:zlp 3:重新启动服务器mssqlserver 我的电脑->控制面版->管理工具->服务->mssqlserver 服务 (更改为:域用户帐号,我们新建的zlp用户 .\zlp,密码:zlp) 4:安装分发服务器 a:配置分发服务器 工具->复制->配置发布、订阅服务器和分发->下一步->下一步(所有的均采用默认配置) b:配置发布服务器 工具->复制->创建和管理发布->选择要发布的数据库(sz)->下一步->快照发布->下一步->选择要发布的内容->下一步->下一步->下一步->完成 c:强制配置订阅服务器(推模式,拉模式与此雷同) 工具->复制->配置发布、订阅服务器和分发->订阅服务器->新建->sql server数据库->输入客户端服务器名称(zlp)->使用sql server 身份验证(sa,空密码)->确定->应用->确定 d:初始化订阅 复制监视器->发布服务器(zehuadb)->双击订阅->强制新建->下一步->选择启用的订阅服务器->zlp->下一步->下一步->下一步->下一步->完成 5:测试配置是否成功 复制监视器->发布衿?zehuadb)->双击sz:sz->点状态->点立即运行代理程序 查看: 复制监视器->发布服务器(zehuadb)->sz:sz->选择zlp:sz(类型强制)->鼠标右键->启动同步处理 如果没有错误标志(红色叉),恭喜您配置成功 6:测试数据 在服务器执行: 选择一个表,执行如下sql: insert into wq_newsgroup_s select '测试成功',5 复制监视器->发布服务器(zehuadb)->sz:sz->快照->启动代理程序 ->zlp:sz(强制)->启动同步处理 去查看同步的 wq_newsgroup_s 是否插入了一条新的记录 测试完毕,通过。 7:修改数据库的同步时间,一般选择夜晚执行数据库同步处理 (具体操作略) :d /* 注意说明: 服务器一端不能以(local)进行数据的发布与分发,需要先删除注册,然后新建注册本地计算机名称 卸载方式:工具->复制->禁止发布->是在"zehuadb"上静止发布,卸载所有的数据库同步配置服务器 注意:发布服务器、分发服务器中的sqlserveragent服务必须启动 采用推模式: "d:\microsoft sql server\mssql\repldata\unc" 目录文件可以不设置共享 拉模式:则需要共享~! */ 少量数据库同步可以采用触发器实现,同步单表即可。 三、配置过程中可能出现的问题 在sql server 2000里设置和使用数据库复制之前,应先检查相关的几台sql server服务器下面几点是否满足: 1、mssqlserver和sqlserveragent服务是否是以域用户身份启动并运行的(.\administrator用户也是可以的) 如果登录用的是本地系统帐户local,将不具备网络功能,会产生以下错误: 进程未能连接到distributor '@server name' (如果您的服务器已经用了sql server全文检索服务, 请不要修改mssqlserver和sqlserveragent服务的local启动。 会照成全文检索服务不能用。请换另外一台机器来做sql server 2000里复制中的分发服务器。) 修改服务启动的登录用户,需要重新启动mssqlserver和sqlserveragent服务才能生效。 2、检查相关的几台sql server服务器是否改过名称(需要srvid=0的本地机器上srvname和datasource一样) 在查询分析器里执行: use master select srvid,srvname,datasource from sysservers 如果没有srvid=0或者srvid=0(也就是本机器)但srvname和datasource不一样, 需要按如下方法修改: use master go -- 设置两个变量 declare @serverproperty_servername varchar(100), @servername varchar(100) -- 取得windows nt 服务器和与指定的 sql server 实例关联的实例信息 select @serverproperty_servername = convert(varchar(100), serverproperty('servername')) -- 返回运行 microsoft sql server 的本地服务器名称 select @servername = convert(varchar(100), @@servername) -- 显示获取的这两个参数 select @serverproperty_servername,@servername --如果@serverproperty_servername和@servername不同(因为你改过计算机名字),再运行下面的 --删除错误的服务器名 exec sp_dropserver @server=@servername --添加正确的服务器名 exec sp_addserver @server=@serverproperty_servername, @local='local' 修改这项参数,需要重新启动mssqlserver和sqlserveragent服务才能生效。 这样一来就不会在创建复制的过程中出现18482、18483错误了。 3、检查sql server企业管理器里面相关的几台sql server注册名是否和上面第二点里介绍的srvname一样 不能用ip地址的注册名。 (我们可以删掉ip地址的注册,新建以sql server管理员级别的用户注册的服务器名) 这样一来就不会在创建复制的过程中出现14010、20084、18456、18482、18483错误了。 4、检查相关的几台sql server服务器网络是否能够正常访问 如果ping主机ip地址可以,但ping主机名不通的时候,需要在 winnt\system32\drivers\etc\hosts (win2000) windows\system32\drivers\etc\hosts (win2003) 文件里写入数据库服务器ip地址和主机名的对应关系。 例如: 127.0.0.1 localhost 192.168.0.35 oracledb oracledb 192.168.0.65 fengyu02 fengyu02 202.84.10.193 bj_db bj_db 或者在sql server客户端网络实用工具里建立别名,例如: 5、系统需要的扩展存储过程是否存在(如果不存在,需要恢复): sp_addextendedproc 'xp_regenumvalues',@dllname ='xpstar.dll' go sp_addextendedproc 'xp_regdeletevalue',@dllname ='xpstar.dll' go sp_addextendedproc 'xp_regdeletekey',@dllname ='xpstar.dll' go sp_addextendedproc xp_cmdshell ,@dllname ='xplog70.dll' 接下来就可以用sql server企业管理器里[复制]-> 右键选择 ->[配置发布、订阅服务器和分发]的图形界面来配置数据库复制了。 下面是按顺序列出配置复制的步骤: 1、建立发布和分发服务器 [欢迎使用配置发布和分发向导]->[选择分发服务器]->[使"@servername"成为它自己的分发服务器,sql server将创建分发数据库和日志] ->[制定快照文件夹]-> [自定义配置] -> [否,使用下列的默认配置] -> [完成] 上述步骤完成后, 会在当前"@servername" sql server数据库里建立了一个distribion库和 一个distributor_admin管理员级别的用户(我们可以任意修改密码)。 服务器上新增加了四个作业: [ 代理程序历史记录清除: distribution ] [ 分发清除: distribution ] [ 复制代理程序检查 ] [ 重新初始化存在数据验证失败的订阅 ] sql server企业管理器里多了一个复制监视器, 当前的这台机器就可以发布、分发、订阅了。 我们再次在sql server企业管理器里[复制]-> 右键选择 ->[配置发布、订阅服务器和分发] 我们可以在 [发布服务器和分发服务器的属性] 窗口-> [发布服务器] -> [新增] -> [确定] -> [发布数据库] -> [事务]/[合并] -> [确定] -> [订阅服务器] -> [新增] -> [确定] 把网络上的其它sql server服务器添加成为发布或者订阅服务器. 新增一台发布服务器的选项: 我这里新建立的jin001发布服务器是用管理员级别的数据库用户test连接的, 到发布服务器的管理链接要输入密码的可选框, 默认的是选中的, 在新建的jin001发布服务器上建立和分发服务器fengyu/fengyu的链接的时需要输入distributor_admin用户的密码。到发布服务器的管理链接要输入密码的可选框,也可以不选,也就是不需要密码来建立发布到分发服务器的链接(这当然欠缺安全,在测试环境下可以使用)。 2、新建立的网络上另一台发布服务器(例如jin001)选择分发服务器 [欢迎使用配置发布和分发向导]->[选择分发服务器] -> 使用下列服务器(选定的服务器必须已配置为分发服务器) -> 选定服务器 -> [下一步] -> [输入分发服务器(例如fengyu/fengyu)的distributor_admin用户的密码两次] -> [下一步] -> [自定义配置] -> [否,使用下列的默认配置] -> [下一步] -> [完成] -> [确定] 建立一个数据库复制发布的过程: [复制] -> [发布内容] -> 右键选择 -> [新建发布] -> [下一步] -> [选择发布数据库] -> [选中一个待发布的数据库] -> [下一步] -> [选择发布类型] -> [事务发布]/[合并发布] -> [下一步] -> [指定订阅服务器的类型] -> [运行sql server 2000的服务器] -> [下一步] -> [指定项目] -> [在事务发布中只可以发布带主键的表] -> [选中一个有主键的待发布的表] ->[在合并发布中会给表增加唯一性索引和 rowguidcol 属性的唯一标识符字段[rowguid],默认值是newid()] (添加新列将: 导致不带列列表的 insert 语句失败,增加表的大小,增加生成第一个快照所要求的时间) ->[选中一个待发布的表] -> [下一步] -> [选择发布名称和描述] -> -> [下一步] -> [自定义发布的属性] -> [否,根据指定方式创建发布] -> [下一步] -> [完成] -> [关闭] 发布属性里有很多有用的选项:设定订阅到期(例如24小时) 设定发布表的项目属性: 常规窗口可以指定发布目的表的名称,可以跟原来的表名称不一样。 下图是命令和快照窗口的栏目 ( sql server 数据库复制技术实际上是用insert,update,delete操作在订阅服务器上重做发布服务器上的事务操作 看文档资料需要把发布数据库设成完全恢复模式,事务才不会丢失 但我自己在测试中发现发布数据库是简单恢复模式下,每10秒生成一些大事务,10分钟后再收缩数据库日志, 这期间发布和订阅服务器上的作业都暂停,暂停恢复后并没有丢失任何事务更改 ) 发布表可以做数据筛选,例如只选择表里面的部分列: 例如只选择表里某些符合条件的记录, 我们可以手工编写筛选的sql语句: 发布表的订阅选项,并可以建立强制订阅: 成功建立了发布以后,发布服务器上新增加了一个作业: [ 失效订阅清除 ] 分发服务器上新增加了两个作业: [ jin001-dack-dack-5 ] 类型[ repl快照 ] [ jin001-dack-3 ] 类型[ repl日志读取器 ] 上面蓝色字的名称会根据发布服务器名,发布名及第几次发布而使用不同的编号 repl快照作业是sql server复制的前提条件,它会先把发布的表结构,数据,索引,约束等生成到发布服务器的os目录下文件 (当有订阅的时候才会生成, 当订阅请求初始化或者按照某个时间表调度生成) repl日志读取器在事务复制的时候是一直处于运行状态。(在合并复制的时候可以根据调度的时间表来运行) 建立一个数据库复制订阅的过程: [复制] -> [订阅] -> 右键选择 -> [新建请求订阅] -> [下一步] -> [查找发布] -> [查看已注册服务器所做的发布] -> [下一步] -> [选择发布] -> [选中已经建立发布服务器上的数据库发布名] -> [下一步] -> [指定同步代理程序登录] -> [当代理程序连接到代理服务器时:使用sql server身份验证] (输入发布服务器上distributor_admin用户名和密码) -> [下一步] -> [选择目的数据库] -> [选择在其中创建订阅的数据库名]/[也可以新建一个库名] -> [下一步] -> [允许匿名订阅] -> [是,生成匿名订阅] -> [下一步] -> [初始化订阅] -> [是,初始化架构和数据] -> [下一步] -> [快照传送] -> [使用该发布的默认快照文件夹中的快照文件] (订阅服务器要能访问发布服务器的repldata文件夹,如果有问题,可以手工设置网络共享及共享权限) -> [下一步] -> [快照传送] -> [使用该发布的默认快照文件夹中的快照文件] -> [下一步] -> [设置分发代理程序调度] -> [使用下列调度] -> [更改] -> [例如每五分钟调度一次] -> [下一步] -> [启动要求的服务] -> [该订阅要求在发布服务器上运行sqlserveragent服务] -> [下一步] -> [完成] -> [确定] 成功建立了订阅后,订阅服务器上新增加了一个类别是[repl-分发]作业(合并复制的时候类别是[repl-合并]) 它会按照我们给的时间调度表运行数据库同步复制的作业。 3、sql server复制配置好后, 可能出现异常情况的实验日志: 1.发布服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制没有多大影响 中断期间,分发和订阅都接收到没有复制的事务信息 2.分发服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制有一些影响 中断期间,发布服务器的事务排队堆积起来 (如果设置了较长时间才删除过期订阅的选项, 繁忙发布数据库的事务日志可能会较快速膨胀), 订阅服务器会因为访问不到发布服务器,反复重试 我们可以设置重试次数和重试的时间间隔(最大的重试次数是9999, 如果每分钟重试一次,可以支持约6.9天不出错) 分发服务器sql server服务启动,网络接通以后,发布服务器上的堆积作业将按时间顺序作用到订阅机器上: 会需要一个比较长的时间(实际上是生成所有事务的insert,update,delete语句,在订阅服务器上去执行) 我们在普通的pc机上实验的58个事务100228个命令执行花了7分28秒. 3.订阅服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制影响比较大,可能需要重新初试化 我们实验环境(订阅服务器)从18:46分意外停机以, 第二天8:40分重启动后, 已经设好的复制在8:40分以后又开始正常运行了, 发布服务器上的堆积作业将按时间顺序作用到订阅机器上, 但复制管理器里出现快照的错误提示, 快照可能需要重新初试化,复制可能需要重新启动.(我们实验环境的机器并没有进行快照初试化,复制仍然是成功运行的) 4、删除已经建好的发布和定阅可以直接用delete删除按钮 我们最好总是按先删定阅,再删发布,最后禁用发布的顺序来操作。 如果要彻底删去sql server上面的复制设置, 可以这样操作: [复制] -> 右键选择 [禁用发布] -> [欢迎使用禁用发布和分发向导] -> [下一步] -> [禁用发布] -> [要在"@servername"上禁用发布] -> [下一步] -> [完成禁用发布和分发向导] -> [完成] 我们也可以用t-sql命令来完成复制中发布及订阅的创建和删除, 选中已经设好的发布和订阅, 按属标右键可以[生成sql脚本]。(这里就不详细讲了, 后面推荐的网站内有比较详细的内容) 当你试图删除或者变更一个table时,出现以下错误 server: msg 3724, level 16, state 2, line 1 cannot drop the table 'object_name' because it is being used for replication. 比较典型的情况是该table曾经用于复制,但是后来又删除了复制。 处理办法: select * from sysobjects where replinfo >'0' sp_configure 'allow updates', 1 go reconfigure with override go begin transaction update sysobjects set replinfo = '0' where replinfo >'0' commit transaction go rollback transaction go sp_configure 'allow updates', 0 go reconfigure with override go 答案来源于网络

养狐狸的猫 2019-12-02 02:18:58 0 浏览量 回答数 0

回答

同步两个SQLServer数据库 如何同步两个sqlserver数据库的内容?程序代码可以有版本管理cvs进行同步管理,可是数据库同步就非常麻烦,只能自己改了一个后再去改另一个,如果忘记了更改另一个经常造成两个数据库的结构或内容上不一致.各位有什么好的方法吗? 一、分发与复制 用强制订阅实现数据库同步操作. 大量和批量的数据可以用数据库的同步机制处理: // 说明: 为方便操作,所有操作均在发布服务器(分发服务器)上操作,并使用推模式 在客户机器使用强制订阅方式。 二、测试通过 1:环境 服务器环境: 机器名称: zehuadb 操作系统:windows 2000 server 数据库版本:sql 2000 server 个人版 客户端 机器名称:zlp 操作系统:windows 2000 server 数据库版本:sql 2000 server 个人版 2:建用户帐号 在服务器端建立域用户帐号 我的电脑管理->本地用户和组->用户->建立 username:zlp userpwd:zlp 3:重新启动服务器mssqlserver 我的电脑->控制面版->管理工具->服务->mssqlserver 服务 (更改为:域用户帐号,我们新建的zlp用户 .\zlp,密码:zlp) 4:安装分发服务器 a:配置分发服务器 工具->复制->配置发布、订阅服务器和分发->下一步->下一步(所有的均采用默认配置) b:配置发布服务器 工具->复制->创建和管理发布->选择要发布的数据库(sz)->下一步->快照发布->下一步->选择要发布的内容->下一步->下一步->下一步->完成 c:强制配置订阅服务器(推模式,拉模式与此雷同) 工具->复制->配置发布、订阅服务器和分发->订阅服务器->新建->sql server数据库->输入客户端服务器名称(zlp)->使用sql server 身份验证(sa,空密码)->确定->应用->确定 d:初始化订阅 复制监视器->发布服务器(zehuadb)->双击订阅->强制新建->下一步->选择启用的订阅服务器->zlp->下一步->下一步->下一步->下一步->完成 5:测试配置是否成功 复制监视器->发布衿?zehuadb)->双击sz:sz->点状态->点立即运行代理程序 查看: 复制监视器->发布服务器(zehuadb)->sz:sz->选择zlp:sz(类型强制)->鼠标右键->启动同步处理 如果没有错误标志(红色叉),恭喜您配置成功 6:测试数据 在服务器执行: 选择一个表,执行如下sql:        insert into wq_newsgroup_s select '测试成功',5 复制监视器->发布服务器(zehuadb)->sz:sz->快照->启动代理程序 ->zlp:sz(强制)->启动同步处理 去查看同步的 wq_newsgroup_s 是否插入了一条新的记录 测试完毕,通过。 7:修改数据库的同步时间,一般选择夜晚执行数据库同步处理 (具体操作略) :d /* 注意说明: 服务器一端不能以(local)进行数据的发布与分发,需要先删除注册,然后新建注册本地计算机名称 卸载方式:工具->复制->禁止发布->是在"zehuadb"上静止发布,卸载所有的数据库同步配置服务器 注意:发布服务器、分发服务器中的sqlserveragent服务必须启动 采用推模式: "d:\microsoft sql server\mssql\repldata\unc" 目录文件可以不设置共享 拉模式:则需要共享~! */ 少量数据库同步可以采用触发器实现,同步单表即可。 三、配置过程中可能出现的问题 在sql server 2000里设置和使用数据库复制之前,应先检查相关的几台sql server服务器下面几点是否满足: 1、mssqlserver和sqlserveragent服务是否是以域用户身份启动并运行的(.\administrator用户也是可以的) 如果登录用的是本地系统帐户local,将不具备网络功能,会产生以下错误: 进程未能连接到distributor '@server name' (如果您的服务器已经用了sql server全文检索服务, 请不要修改mssqlserver和sqlserveragent服务的local启动。 会照成全文检索服务不能用。请换另外一台机器来做sql server 2000里复制中的分发服务器。) 修改服务启动的登录用户,需要重新启动mssqlserver和sqlserveragent服务才能生效。 2、检查相关的几台sql server服务器是否改过名称(需要srvid=0的本地机器上srvname和datasource一样) 在查询分析器里执行: use master select srvid,srvname,datasource from sysservers 如果没有srvid=0或者srvid=0(也就是本机器)但srvname和datasource不一样, 需要按如下方法修改: use master go -- 设置两个变量 declare @serverproperty_servername  varchar(100), @servername    varchar(100) -- 取得windows nt 服务器和与指定的 sql server 实例关联的实例信息 select @serverproperty_servername = convert(varchar(100), serverproperty('servername')) -- 返回运行 microsoft sql server 的本地服务器名称 select @servername = convert(varchar(100), @@servername) -- 显示获取的这两个参数 select @serverproperty_servername,@servername --如果@serverproperty_servername和@servername不同(因为你改过计算机名字),再运行下面的 --删除错误的服务器名 exec sp_dropserver @server=@servername --添加正确的服务器名 exec sp_addserver @server=@serverproperty_servername, @local='local' 修改这项参数,需要重新启动mssqlserver和sqlserveragent服务才能生效。 这样一来就不会在创建复制的过程中出现18482、18483错误了。 3、检查sql server企业管理器里面相关的几台sql server注册名是否和上面第二点里介绍的srvname一样 不能用ip地址的注册名。 (我们可以删掉ip地址的注册,新建以sql server管理员级别的用户注册的服务器名) 这样一来就不会在创建复制的过程中出现14010、20084、18456、18482、18483错误了。 4、检查相关的几台sql server服务器网络是否能够正常访问 如果ping主机ip地址可以,但ping主机名不通的时候,需要在 winnt\system32\drivers\etc\hosts   (win2000) windows\system32\drivers\etc\hosts (win2003) 文件里写入数据库服务器ip地址和主机名的对应关系。 例如: 127.0.0.1       localhost 192.168.0.35    oracledb    oracledb 192.168.0.65    fengyu02    fengyu02 202.84.10.193   bj_db       bj_db 或者在sql server客户端网络实用工具里建立别名,例如: 5、系统需要的扩展存储过程是否存在(如果不存在,需要恢复): sp_addextendedproc 'xp_regenumvalues',@dllname ='xpstar.dll' go sp_addextendedproc 'xp_regdeletevalue',@dllname ='xpstar.dll' go sp_addextendedproc 'xp_regdeletekey',@dllname ='xpstar.dll' go sp_addextendedproc xp_cmdshell ,@dllname ='xplog70.dll'  接下来就可以用sql server企业管理器里[复制]-> 右键选择 ->[配置发布、订阅服务器和分发]的图形界面来配置数据库复制了。 下面是按顺序列出配置复制的步骤: 1、建立发布和分发服务器 [欢迎使用配置发布和分发向导]->[选择分发服务器]->[使"@servername"成为它自己的分发服务器,sql server将创建分发数据库和日志] ->[制定快照文件夹]-> [自定义配置] -> [否,使用下列的默认配置] -> [完成] 上述步骤完成后, 会在当前"@servername" sql server数据库里建立了一个distribion库和 一个distributor_admin管理员级别的用户(我们可以任意修改密码)。 服务器上新增加了四个作业: [ 代理程序历史记录清除: distribution ] [ 分发清除: distribution ] [ 复制代理程序检查 ] [ 重新初始化存在数据验证失败的订阅 ] sql server企业管理器里多了一个复制监视器, 当前的这台机器就可以发布、分发、订阅了。 我们再次在sql server企业管理器里[复制]-> 右键选择 ->[配置发布、订阅服务器和分发] 我们可以在 [发布服务器和分发服务器的属性] 窗口-> [发布服务器] -> [新增]   -> [确定] -> [发布数据库] -> [事务]/[合并] -> [确定]  -> [订阅服务器] -> [新增]  -> [确定] 把网络上的其它sql server服务器添加成为发布或者订阅服务器. 新增一台发布服务器的选项: 我这里新建立的jin001发布服务器是用管理员级别的数据库用户test连接的, 到发布服务器的管理链接要输入密码的可选框, 默认的是选中的, 在新建的jin001发布服务器上建立和分发服务器fengyu/fengyu的链接的时需要输入distributor_admin用户的密码。到发布服务器的管理链接要输入密码的可选框,也可以不选,也就是不需要密码来建立发布到分发服务器的链接(这当然欠缺安全,在测试环境下可以使用)。 2、新建立的网络上另一台发布服务器(例如jin001)选择分发服务器 [欢迎使用配置发布和分发向导]->[选择分发服务器] -> 使用下列服务器(选定的服务器必须已配置为分发服务器) -> [选定服务器](例如fengyu/fengyu) -> [下一步] -> [输入分发服务器(例如fengyu/fengyu)的distributor_admin用户的密码两次] -> [下一步] -> [自定义配置] -> [否,使用下列的默认配置] -> [下一步] -> [完成] -> [确定] 建立一个数据库复制发布的过程: [复制] -> [发布内容] -> 右键选择 -> [新建发布] -> [下一步] -> [选择发布数据库] -> [选中一个待发布的数据库] -> [下一步] -> [选择发布类型] -> [事务发布]/[合并发布] -> [下一步] -> [指定订阅服务器的类型] -> [运行sql server 2000的服务器] -> [下一步] -> [指定项目] -> [在事务发布中只可以发布带主键的表] -> [选中一个有主键的待发布的表] ->[在合并发布中会给表增加唯一性索引和 rowguidcol 属性的唯一标识符字段[rowguid],默认值是newid()] (添加新列将: 导致不带列列表的 insert 语句失败,增加表的大小,增加生成第一个快照所要求的时间) ->[选中一个待发布的表] -> [下一步] -> [选择发布名称和描述] -> -> [下一步] -> [自定义发布的属性] -> [否,根据指定方式创建发布] -> [下一步] -> [完成] -> [关闭] 发布属性里有很多有用的选项:设定订阅到期(例如24小时) 设定发布表的项目属性: 常规窗口可以指定发布目的表的名称,可以跟原来的表名称不一样。 下图是命令和快照窗口的栏目 ( sql server 数据库复制技术实际上是用insert,update,delete操作在订阅服务器上重做发布服务器上的事务操作 看文档资料需要把发布数据库设成完全恢复模式,事务才不会丢失 但我自己在测试中发现发布数据库是简单恢复模式下,每10秒生成一些大事务,10分钟后再收缩数据库日志, 这期间发布和订阅服务器上的作业都暂停,暂停恢复后并没有丢失任何事务更改 ) 发布表可以做数据筛选,例如只选择表里面的部分列: 例如只选择表里某些符合条件的记录, 我们可以手工编写筛选的sql语句: 发布表的订阅选项,并可以建立强制订阅: 成功建立了发布以后,发布服务器上新增加了一个作业: [ 失效订阅清除 ] 分发服务器上新增加了两个作业: [ jin001-dack-dack-5 ] 类型[ repl快照 ] [ jin001-dack-3 ]      类型[ repl日志读取器 ] 上面蓝色字的名称会根据发布服务器名,发布名及第几次发布而使用不同的编号 repl快照作业是sql server复制的前提条件,它会先把发布的表结构,数据,索引,约束等生成到发布服务器的os目录下文件 (当有订阅的时候才会生成, 当订阅请求初始化或者按照某个时间表调度生成) repl日志读取器在事务复制的时候是一直处于运行状态。(在合并复制的时候可以根据调度的时间表来运行) 建立一个数据库复制订阅的过程: [复制] -> [订阅] -> 右键选择 -> [新建请求订阅] -> [下一步] -> [查找发布] -> [查看已注册服务器所做的发布] -> [下一步] -> [选择发布] -> [选中已经建立发布服务器上的数据库发布名] -> [下一步] -> [指定同步代理程序登录] -> [当代理程序连接到代理服务器时:使用sql server身份验证] (输入发布服务器上distributor_admin用户名和密码) -> [下一步] -> [选择目的数据库] -> [选择在其中创建订阅的数据库名]/[也可以新建一个库名] -> [下一步] -> [允许匿名订阅] -> [是,生成匿名订阅] -> [下一步] -> [初始化订阅] -> [是,初始化架构和数据] -> [下一步] -> [快照传送] -> [使用该发布的默认快照文件夹中的快照文件] (订阅服务器要能访问发布服务器的repldata文件夹,如果有问题,可以手工设置网络共享及共享权限) -> [下一步] -> [快照传送] -> [使用该发布的默认快照文件夹中的快照文件] -> [下一步] -> [设置分发代理程序调度] -> [使用下列调度] -> [更改] -> [例如每五分钟调度一次] -> [下一步] -> [启动要求的服务] -> [该订阅要求在发布服务器上运行sqlserveragent服务] -> [下一步] -> [完成] -> [确定] 成功建立了订阅后,订阅服务器上新增加了一个类别是[repl-分发]作业(合并复制的时候类别是[repl-合并]) 它会按照我们给的时间调度表运行数据库同步复制的作业。 3、sql server复制配置好后, 可能出现异常情况的实验日志: 1.发布服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制没有多大影响 中断期间,分发和订阅都接收到没有复制的事务信息 2.分发服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制有一些影响 中断期间,发布服务器的事务排队堆积起来 (如果设置了较长时间才删除过期订阅的选项, 繁忙发布数据库的事务日志可能会较快速膨胀), 订阅服务器会因为访问不到发布服务器,反复重试 我们可以设置重试次数和重试的时间间隔(最大的重试次数是9999, 如果每分钟重试一次,可以支持约6.9天不出错) 分发服务器sql server服务启动,网络接通以后,发布服务器上的堆积作业将按时间顺序作用到订阅机器上: 会需要一个比较长的时间(实际上是生成所有事务的insert,update,delete语句,在订阅服务器上去执行) 我们在普通的pc机上实验的58个事务100228个命令执行花了7分28秒. 3.订阅服务器断网,sql server服务关闭,重启动,关机的时候,对已经设置好的复制影响比较大,可能需要重新初试化 我们实验环境(订阅服务器)从18:46分意外停机以, 第二天8:40分重启动后, 已经设好的复制在8:40分以后又开始正常运行了, 发布服务器上的堆积作业将按时间顺序作用到订阅机器上, 但复制管理器里出现快照的错误提示, 快照可能需要重新初试化,复制可能需要重新启动.(我们实验环境的机器并没有进行快照初试化,复制仍然是成功运行的) 4、删除已经建好的发布和定阅可以直接用delete删除按钮 我们最好总是按先删定阅,再删发布,最后禁用发布的顺序来操作。 如果要彻底删去sql server上面的复制设置, 可以这样操作: [复制] -> 右键选择 [禁用发布] -> [欢迎使用禁用发布和分发向导] -> [下一步] -> [禁用发布] -> [要在"@servername"上禁用发布] -> [下一步] -> [完成禁用发布和分发向导] -> [完成] 我们也可以用t-sql命令来完成复制中发布及订阅的创建和删除, 选中已经设好的发布和订阅, 按属标右键可以[生成sql脚本]。(这里就不详细讲了, 后面推荐的网站内有比较详细的内容) 当你试图删除或者变更一个table时,出现以下错误 server: msg 3724, level 16, state 2, line 1 cannot drop the table 'object_name' because it is being used for replication. 比较典型的情况是该table曾经用于复制,但是后来又删除了复制。 处理办法: select * from sysobjects where replinfo >'0' sp_configure 'allow updates', 1 go reconfigure with override go begin transaction update sysobjects set replinfo = '0' where replinfo >'0' commit transaction go rollback transaction go sp_configure 'allow updates', 0 go reconfigure with override go 答案来源网络,供参考,希望对您有帮助

问问小秘 2019-12-02 03:02:42 0 浏览量 回答数 0

问题

词汇表是什么样的?(S-V)

轩墨 2019-12-01 22:06:08 2089 浏览量 回答数 0

回答

请参考个人博客:https://blog.csdn.net/u010870518/article/details/79450295 在进一步分析为什么MySQL数据库索引选择使用B+树之前,我相信很多小伙伴对数据结构中的树还是有些许模糊的,因此我们由浅入深一步步探讨树的演进过程,在一步步引出B树以及为什么MySQL数据库索引选择使用B+树! 学过数据结构的一般对最基础的树都有所认识,因此我们就从与我们主题更为相近的二叉查找树开始。 一、二叉查找树 (1)二叉树简介: 二叉查找树也称为有序二叉查找树,满足二叉查找树的一般性质,是指一棵空树具有如下性质: 1、任意节点左子树不为空,则左子树的值均小于根节点的值; 2、任意节点右子树不为空,则右子树的值均大于于根节点的值; 3、任意节点的左右子树也分别是二叉查找树; 4、没有键值相等的节点; 上图为一个普通的二叉查找树,按照中序遍历的方式可以从小到大的顺序排序输出:2、3、5、6、7、8。 对上述二叉树进行查找,如查键值为5的记录,先找到根,其键值是6,6大于5,因此查找6的左子树,找到3;而5大于3,再找其右子树;一共找了3次。如果按2、3、5、6、7、8的顺序来找同样需求3次。用同样的方法在查找键值为8的这个记录,这次用了3次查找,而顺序查找需要6次。计算平均查找次数得:顺序查找的平均查找次数为(1+2+3+4+5+6)/ 6 = 3.3次,二叉查找树的平均查找次数为(3+3+3+2+2+1)/6=2.3次。二叉查找树的平均查找速度比顺序查找来得更快。 (2)局限性及应用 一个二叉查找树是由n个节点随机构成,所以,对于某些情况,二叉查找树会退化成一个有n个节点的线性链。如下图: 大家看上图,如果我们的根节点选择是最小或者最大的数,那么二叉查找树就完全退化成了线性结构。上图中的平均查找次数为(1+2+3+4+5+5)/6=3.16次,和顺序查找差不多。显然这个二叉树的查询效率就很低,因此若想最大性能的构造一个二叉查找树,需要这个二叉树是平衡的(这里的平衡从一个显著的特点可以看出这一棵树的高度比上一个输的高度要大,在相同节点的情况下也就是不平衡),从而引出了一个新的定义-平衡二叉树AVL。 二、AVL树 (1)简介 AVL树是带有平衡条件的二叉查找树,一般是用平衡因子差值判断是否平衡并通过旋转来实现平衡,左右子树树高不超过1,和红黑树相比,它是严格的平衡二叉树,平衡条件必须满足(所有节点的左右子树高度差不超过1)。不管我们是执行插入还是删除操作,只要不满足上面的条件,就要通过旋转来保持平衡,而旋转是非常耗时的,由此我们可以知道AVL树适合用于插入删除次数比较少,但查找多的情况。 从上面是一个普通的平衡二叉树,这张图我们可以看出,任意节点的左右子树的平衡因子差值都不会大于1。 (2)局限性 由于维护这种高度平衡所付出的代价比从中获得的效率收益还大,故而实际的应用不多,更多的地方是用追求局部而不是非常严格整体平衡的红黑树。当然,如果应用场景中对插入删除不频繁,只是对查找要求较高,那么AVL还是较优于红黑树。 (3)应用 1、Windows NT内核中广泛存在; 三、红黑树 (1)简介 一种二叉查找树,但在每个节点增加一个存储位表示节点的颜色,可以是red或black。通过对任何一条从根到叶子的路径上各个节点着色的方式的限制,红黑树确保没有一条路径会比其它路径长出两倍。它是一种弱平衡二叉树(由于是若平衡,可以推出,相同的节点情况下,AVL树的高度低于红黑树),相对于要求严格的AVL树来说,它的旋转次数变少,所以对于搜索、插入、删除操作多的情况下,我们就用红黑树。 (2)性质 1、每个节点非红即黑; 2、根节点是黑的; 3、每个叶节点(叶节点即树尾端NULL指针或NULL节点)都是黑的; 4、如果一个节点是红的,那么它的两儿子都是黑的; 5、对于任意节点而言,其到叶子点树NULL指针的每条路径都包含相同数目的黑节点; 6、每条路径都包含相同的黑节点; (3)应用 1、广泛用于C++的STL中,Map和Set都是用红黑树实现的; 2、著名的Linux进程调度Completely Fair Scheduler,用红黑树管理进程控制块,进程的虚拟内存区域都存储在一颗红黑树上,每个虚拟地址区域都对应红黑树的一个节点,左指针指向相邻的地址虚拟存储区域,右指针指向相邻的高地址虚拟地址空间; 3、IO多路复用epoll的实现采用红黑树组织管理sockfd,以支持快速的增删改查; 4、Nginx中用红黑树管理timer,因为红黑树是有序的,可以很快的得到距离当前最小的定时器; 5、Java中TreeMap的实现; 四、B/B+树 说了上述的三种树:二叉查找树、AVL和红黑树,似乎我们还没有摸到MySQL为什么要使用B+树作为索引的实现,不要急,接下来我们就先探讨一下什么是B树。 (1)简介 我们在MySQL中的数据一般是放在磁盘中的,读取数据的时候肯定会有访问磁盘的操作,磁盘中有两个机械运动的部分,分别是盘片旋转和磁臂移动。盘片旋转就是我们市面上所提到的多少转每分钟,而磁盘移动则是在盘片旋转到指定位置以后,移动磁臂后开始进行数据的读写。那么这就存在一个定位到磁盘中的块的过程,而定位是磁盘的存取中花费时间比较大的一块,毕竟机械运动花费的时候要远远大于电子运动的时间。当大规模数据存储到磁盘中的时候,显然定位是一个非常花费时间的过程,但是我们可以通过B树进行优化,提高磁盘读取时定位的效率。 为什么B类树可以进行优化呢?我们可以根据B类树的特点,构造一个多阶的B类树,然后在尽量多的在结点上存储相关的信息,保证层数尽量的少,以便后面我们可以更快的找到信息,磁盘的I/O操作也少一些,而且B类树是平衡树,每个结点到叶子结点的高度都是相同,这也保证了每个查询是稳定的。 总的来说,B/B+树是为了磁盘或其它存储设备而设计的一种平衡多路查找树(相对于二叉,B树每个内节点有多个分支),与红黑树相比,在相同的的节点的情况下,一颗B/B+树的高度远远小于红黑树的高度(在下面B/B+树的性能分析中会提到)。B/B+树上操作的时间通常由存取磁盘的时间和CPU计算时间这两部分构成,而CPU的速度非常快,所以B树的操作效率取决于访问磁盘的次数,关键字总数相同的情况下B树的高度越小,磁盘I/O所花的时间越少。 注意B-树就是B树,-只是一个符号。 (2)B树的性质 1、定义任意非叶子结点最多只有M个儿子,且M>2; 2、根结点的儿子数为[2, M]; 3、除根结点以外的非叶子结点的儿子数为[M/2, M]; 4、每个结点存放至少M/2-1(取上整)和至多M-1个关键字;(至少2个关键字) 5、非叶子结点的关键字个数=指向儿子的指针个数-1; 6、非叶子结点的关键字:K[1], K[2], …, K[M-1];且K[i] < K[i+1]; 7、非叶子结点的指针:P[1], P[2], …, P[M];其中P[1]指向关键字小于K[1]的子树,P[M]指向关键字大于K[M-1]的子树,其它P[i]指向关键字属于(K[i-1], K[i])的子树; 8、所有叶子结点位于同一层; 这里只是一个简单的B树,在实际中B树节点中关键字很多的,上面的图中比如35节点,35代表一个key(索引),而小黑块代表的是这个key所指向的内容在内存中实际的存储位置,是一个指针。 五、B+树 (1)简介 B+树是应文件系统所需而产生的一种B树的变形树(文件的目录一级一级索引,只有最底层的叶子节点(文件)保存数据)非叶子节点只保存索引,不保存实际的数据,数据都保存在叶子节点中,这不就是文件系统文件的查找吗? 我们就举个文件查找的例子:有3个文件夹a、b、c, a包含b,b包含c,一个文件yang.c,a、b、c就是索引(存储在非叶子节点), a、b、c只是要找到的yang.c的key,而实际的数据yang.c存储在叶子节点上。 所有的非叶子节点都可以看成索引部分! (2)B+树的性质(下面提到的都是和B树不相同的性质) 1、非叶子节点的子树指针与关键字个数相同; 2、非叶子节点的子树指针p[i],指向关键字值属于[k[i],k[i+1]]的子树.(B树是开区间,也就是说B树不允许关键字重复,B+树允许重复); 3、为所有叶子节点增加一个链指针; 4、所有关键字都在叶子节点出现(稠密索引). (且链表中的关键字恰好是有序的); 5、非叶子节点相当于是叶子节点的索引(稀疏索引),叶子节点相当于是存储(关键字)数据的数据层; 6、更适合于文件系统; 非叶子节点(比如5,28,65)只是一个key(索引),实际的数据存在叶子节点上(5,8,9)才是真正的数据或指向真实数据的指针。 (3)应用 1、B和B+树主要用在文件系统以及数据库做索引,比如MySQL; 六、B/B+树性能分析 n个节点的平衡二叉树的高度为H(即logn),而n个节点的B/B+树的高度为logt((n+1)/2)+1;   若要作为内存中的查找表,B树却不一定比平衡二叉树好,尤其当m较大时更是如此。因为查找操作CPU的时间在B-树上是O(mlogtn)=O(lgn(m/lgt)),而m/lgt>1;所以m较大时O(mlogtn)比平衡二叉树的操作时间大得多。因此在内存中使用B树必须取较小的m。(通常取最小值m=3,此时B-树中每个内部结点可以有2或3个孩子,这种3阶的B-树称为2-3树)。 七、为什么说B+树比B树更适合数据库索引? 1、 B+树的磁盘读写代价更低:B+树的内部节点并没有指向关键字具体信息的指针,因此其内部节点相对B树更小,如果把所有同一内部节点的关键字存放在同一盘块中,那么盘块所能容纳的关键字数量也越多,一次性读入内存的需要查找的关键字也就越多,相对IO读写次数就降低了。 2、B+树的查询效率更加稳定:由于非终结点并不是最终指向文件内容的结点,而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同,导致每一个数据的查询效率相当。 3、由于B+树的数据都存储在叶子结点中,分支结点均为索引,方便扫库,只需要扫一遍叶子结点即可,但是B树因为其分支结点同样存储着数据,我们要找到具体的数据,需要进行一次中序遍历按序来扫,所以B+树更加适合在区间查询的情况,所以通常B+树用于数据库索引。 PS:我在知乎上看到有人是这样说的,我感觉说的也挺有道理的: 他们认为数据库索引采用B+树的主要原因是:B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题,正是为了解决这个问题,B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的,而B树不支持这样的操作或者说效率太低。 ———————————————— 版权声明:本文为CSDN博主「徐刘根」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/u010870518/java/article/details/79450295

AA大大官 2020-03-31 14:54:01 0 浏览量 回答数 0

回答

前言 这期我想写很久了,但是因为时间的原因一直拖到了现在,我以为一两天就写完了,结果从构思到整理资料,再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的,所以我肯定不会一本正经的写,我想了好几个切入点,最后决定用一个完整的电商系统作为切入点,带着大家看看,我们需要学些啥,我甚至还收集配套视频和资料,暖男石锤啊,这期是呕心沥血之作,不要白嫖了。 正文 在写这个文章之前,我花了点时间,自己臆想了一个电商系统,基本上算是麻雀虽小五脏俱全,我今天就用它开刀,一步步剖析,我会讲一下我们可能会接触的技术栈可能不全,但是够用,最后给个学习路线。 Tip:请多欣赏一会,每个点看一下,看看什么地方是你接触过的,什么技术栈是你不太熟悉的,我觉得还算是比较全的,有什么建议也可以留言给我。 不知道大家都看了一下没,现在我们就要庖丁解牛了,我从上到下依次分析。 前端 你可能会会好奇,你不是讲后端学习路线嘛,为啥还有前端的部分,我只能告诉你,傻瓜,肤浅。 我们可不能闭门造车,谁告诉你后端就不学点前端了? 前端现在很多也了解后端的技术栈的,你想我们去一个网站,最先接触的,最先看到的是啥? 没错就是前端,在大学你要是找不到专门的前端同学,去做系统肯定也要自己顶一下前端的,那我觉得最基本的技术栈得熟悉和了解吧,丙丙现在也是偶尔会开发一下我们的管理系统主要是VUE和React。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的,在以后开发的时候,公司有前端那能帮助你前后端联调更顺畅,如果没前端你自己也能顶一下简单的页面。 HTML、CSS、JS、Ajax我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单,只是精通很难很难。 在这一层不光有这些还有Http协议和Servlet,request、response、cookie、session这些也会伴随你整个技术生涯,理解他们对后面的你肯定有不少好处。 Tip:我这里最后删除了JSP相关的技术,我个人觉得没必要学了,很多公司除了老项目之外,新项目都不会使用那些技术了。 前端在我看来比后端难,技术迭代比较快,知识好像也没特定的体系,所以面试大厂的前端很多朋友都说难,不是技术多难,而是知识多且复杂,找不到一个完整的体系,相比之下后端明朗很多,我后面就开始讲后端了。 网关层: 互联网发展到现在,涌现了很多互联网公司,技术更新迭代了很多个版本,从早期的单机时代,到现在超大规模的互联网时代,几亿人参与的春运,几千亿成交规模的双十一,无数互联网前辈的造就了现在互联网的辉煌。 微服务,分布式,负载均衡等我们经常提到的这些名词都是这些技术在场景背后支撑。 单机顶不住,我们就多找点服务器,但是怎么将流量均匀的打到这些服务器上呢? 负载均衡,LVS 我们机器都是IP访问的,那怎么通过我们申请的域名去请求到服务器呢? DNS 大家刷的抖音,B站,快手等等视频服务商,是怎么保证同时为全国的用户提供快速的体验? CDN 我们这么多系统和服务,还有这么多中间件的调度怎么去管理调度等等? zk 这么多的服务器,怎么对外统一访问呢,就可能需要知道反向代理的服务器。 Nginx 这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了,大家公司的内外网隔离也是这一层做的。 我之前还接触过一些比较有意思的项目,所有对外的接口都是加密的,几十个服务会经过网关解密,找到真的路由再去请求。 这一层的知识点其实也不少,你往后面学会发现分布式事务,分布式锁,还有很多中间件都离不开zk这一层,我们继续往下看。 服务层: 这一层有点东西了,算是整个框架的核心,如果你跟我帅丙一样以后都是从事后端开发的话,我们基本上整个技术生涯,大部分时间都在跟这一层的技术栈打交道了,各种琳琅满目的中间件,计算机基础知识,Linux操作,算法数据结构,架构框架,研发工具等等。 我想在看这个文章的各位,计算机基础肯定都是学过的吧,如果大学的时候没好好学,我觉得还是有必要再看看的。 为什么我们网页能保证安全可靠的传输,你可能会了解到HTTP,TCP协议,什么三次握手,四次挥手。 还有进程、线程、协程,什么内存屏障,指令乱序,分支预测,CPU亲和性等等,在之后的编程生涯,如果你能掌握这些东西,会让你在遇到很多问题的时候瞬间get到点,而不是像个无头苍蝇一样乱撞(然而丙丙还做得不够)。 了解这些计算机知识后,你就需要接触编程语言了,大学的C语言基础会让你学什么语言入门都会快点,我选择了面向对象的JAVA,但是也不知道为啥现在还没对象。 JAVA的基础也一样重要,面向对象(包括类、对象、方法、继承、封装、抽象、 多态、消息解析等),常见API,数据结构,集合框架,设计模式(包括创建型、结构型、行为型),多线程和并发,I/O流,Stream,网络编程你都需要了解。 代码会写了,你就要开始学习一些能帮助你把系统变得更加规范的框架,SSM可以会让你的开发更加便捷,结构层次更加分明。 写代码的时候你会发现你大学用的Eclipse在公司看不到了,你跟大家一样去用了IDEA,第一天这是什么玩意,一周后,真香,但是这玩意收费有点贵,那免费的VSCode真的就是不错的选择了。 代码写的时候你会接触代码的仓库管理工具maven、Gradle,提交代码的时候会去写项目版本管理工具Git。 代码提交之后,发布之后你会发现很多东西需要自己去服务器亲自排查,那Linux的知识点就可以在里面灵活运用了,查看进程,查看文件,各种Vim操作等等。 系统的优化很多地方没优化的空间了,你可能会尝试从算法,或者优化数据结构去优化,你看到了HashMap的源码,想去了解红黑树,然后在算法网上看到了二叉树搜索树和各种常见的算法问题,刷多了,你也能总结出精华所在,什么贪心,分治,动态规划等。 这么多个服务,你发现HTTP请求已经开始有点不满足你的需求了,你想开发更便捷,像访问本地服务一样访问远程服务,所以我们去了解了Dubbo,Spring cloud。 了解Dubbo的过程中,你发现了RPC的精华所在,所以你去接触到了高性能的NIO框架,Netty。 代码写好了,服务也能通信了,但是你发现你的代码链路好长,都耦合在一起了,所以你接触了消息队列,这种异步的处理方式,真香。 他还可以帮你在突发流量的时候用队列做缓冲,但是你发现分布式的情况,事务就不好管理了,你就了解到了分布式事务,什么两段式,三段式,TCC,XA,阿里云的全局事务服务GTS等等。 分布式事务的时候你会想去了解RocketMQ,因为他自带了分布式事务的解决方案,大数据的场景你又看到了Kafka。 我上面提到过zk,像Dubbo、Kafka等中间件都是用它做注册中心的,所以很多技术栈最后都组成了一个知识体系,你先了解了体系中的每一员,你才能把它们联系起来。 服务的交互都从进程内通信变成了远程通信,所以性能必然会受到一些影响。 此外由于很多不确定性的因素,例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等,需要许多额外的功能和措施才能保证微服务流畅稳定的工作。 **Spring Cloud **中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。 你感觉学习得差不多了,你发现各大论坛博客出现了一些前沿技术,比如容器化,你可能就会去了解容器化的知识,像**Docker,Kubernetes(K8s)**等。 微服务之所以能够快速发展,很重要的一个原因就是:容器化技术的发展和容器管理系统的成熟。 这一层的东西呢其实远远不止这些的,我不过多赘述,写多了像个劝退师一样,但是大家也不用慌,大部分的技术都是慢慢接触了,工作中慢慢去了解,去深入的。 好啦我们继续沿着图往下看,那再往下是啥呢? 数据层: 数据库可能是整个系统中最值钱的部分了,在我码文字的前一天,刚好发生了微盟程序员删库跑路的操作,删库跑路其实是我们在网上最常用的笑话,没想到还是照进了现实。 这里也提一点点吧,36小时的故障,其实在互联网公司应该是个笑话了吧,权限控制没做好类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的,备份,全量备份,增量备份,延迟备份,异地容灾全部都考虑一下应该也不至于这样,一家上市公司还是有点点不应该。 数据库基本的事务隔离级别,索引,SQL,主被同步,读写分离等都可能是你学的时候要了解到的。 上面我们提到了安全,不要把鸡蛋放一个篮子的道理大家应该都知道,那分库的意义就很明显了,然后你会发现时间久了表的数据大了,就会想到去接触分表,什么TDDL、Sharding-JDBC、DRDS这些插件都会接触到。 你发现流量大的时候,或者热点数据打到数据库还是有点顶不住,压力太大了,那非关系型数据库就进场了,Redis当然是首选,但是MongoDB、memcache也有各自的应用场景。 Redis使用后,真香,真快,但是你会开始担心最开始提到的安全问题,这玩意快是因为在内存中操作,那断点了数据丢了怎么办?你就开始阅读官方文档,了解RDB,AOF这些持久化机制,线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。 单机不满足你就用了,他的集群模式,用了集群可能也担心集群的健康状态,所以就得去了解哨兵,他的主从同步,时间久了Key多了,就得了解内存淘汰机制…… 他的大容量存储有问题,你可能需要去了解Pika…. 其实远远没完,每个的点我都点到为止,但是其实要深究每个点都要学很久,我们接着往下看。 实时/离线/大数据 等你把几种关系型非关系型数据库的知识点,整理清楚后,你会发现数据还是大啊,而且数据的场景越来越多多样化了,那大数据的各种中间件你就得了解了。 你会发现很多场景,不需要实时的数据,比如你查你的支付宝去年的,上个月的账单,这些都是不会变化的数据,没必要实时,那你可能会接触像ODPS这样的中间件去做数据的离线分析。 然后你可能会接触Hadoop系列相关的东西,比如于Hadoop(HDFS)的一个数据仓库工具Hive,是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase 。 写多的场景,适合做一些简单查询,用他们又有点大材小用,那Cassandra就再合适不过了。 离线的数据分析没办法满足一些实时的常见,类似风控,那Flink你也得略知一二,他的窗口思想还是很有意思。 数据接触完了,计算引擎Spark你是不是也不能放过…… 搜索引擎: 传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题,比如我们在百度,淘宝搜索东西的时候,往往都是几个关键字在一起一起搜索东西的,在数据库除非把几次的结果做交集,不然很难去实现。 那全文检索引擎就诞生了,解决了搜索的问题,你得思考怎么把数据库的东西实时同步到ES中去,那你可能会思考到logstash去定时跑脚本同步,又或者去接触伪装成一台MySQL从服务的Canal,他会去订阅MySQL主服务的binlog,然后自己解析了去操作Es中的数据。 这些都搞定了,那可视化的后台查询又怎么解决呢?Kibana,他他是一个可视化的平台,甚至对Es集群的健康管理都做了可视化,很多公司的日志查询系统都是用它做的。 学习路线 看了这么久你是不是发现,帅丙只是一直在介绍每个层级的技术栈,并没说到具体的一个路线,那是因为我想让大家先有个认知或者说是扫盲吧,我一样用脑图的方式汇总一下吧,如果图片被平台二压了。 资料/学习网站 Tip:本来这一栏有很多我准备的资料的,但是都是外链,或者不合适的分享方式,博客的运营小姐姐提醒了我,所以大家去公众号回复【路线】好了。 絮叨 如果你想去一家不错的公司,但是目前的硬实力又不到,我觉得还是有必要去努力一下的,技术能力的高低能决定你走多远,平台的高低,能决定你的高度。 如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。 丙丙发现在工作中发现我身边的人真的就是实力越强的越努力,最高级的自律,享受孤独(周末的歪哥)。 总结 我提到的技术栈你想全部了解,我觉得初步了解可能几个月就够了,这里的了解仅限于你知道它,知道他是干嘛的,知道怎么去使用它,并不是说深入了解他的底层原理,了解他的常见问题,熟悉问题的解决方案等等。 你想做到后者,基本上只能靠时间上的日积月累,或者不断的去尝试积累经验,也没什么速成的东西,欲速则不达大家也是知道的。 技术这条路,说实话很枯燥,很辛苦,但是待遇也会高于其他一些基础岗位。 所实话我大学学这个就是为了兴趣,我从小对电子,对计算机都比较热爱,但是现在打磨得,现在就是为了钱吧,是不是很现实?若家境殷实,谁愿颠沛流离。 但是至少丙丙因为做软件,改变了家庭的窘境,自己日子也向小康一步步迈过去。 说做程序员改变了我和我家人的一生可能夸张了,但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。 我是敖丙,一个在互联网苟且偷生的工具人。 创作不易,本期硬核,不想被白嫖,各位的「三连」就是丙丙创作的最大动力,我们下次见! 本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。 该回答来自:敖丙

剑曼红尘 2020-03-06 11:35:37 0 浏览量 回答数 0

回答

燃财经(ID:rancaijing)原创 作者 | 唐亚华 编辑 | 魏佳 春节临近,一年一度人口大迁移又要来临。 虽然12306近日已经宣称屏蔽了部分抢票软件,并推出官方候补功能,但市面上提供抢票服务的仍然有智行火车票、 高铁管家、携程、美团、飞猪、同程艺龙等60多个软件。 不过,多名用户反馈称“这届抢票软件不行”,即便用了加速包、买了VIP会员还是抢不到票。技术专家告诉燃财经,从原理上来说,抢票软件只是将用户手动购买车票的链路照搬,用机器来操作,利用企业带宽和机器速度来当“代购”。购买了加速包或VIP的不同之处在于,刷新的频率可能会从30秒一次变成10秒一次或5秒一次,或者多个服务器同时抢票。但是,能不能抢到票仍然是概率问题。 即便如此,仍有众多抢票软件在加速包、VIP会员、优先出票权、安心抢等名目上“动脑筋”,燃财经测试发现,如果要一步一步升级到“抢票顶配”,在携程上需要花费138元,在美团上需要花费80元。这也让不少人诟病抢票软件有捆绑、诱导消费之嫌。 事实上,抢票难的根源在于春节这样短期的大规模迁徙带来的巨大需求缺口难以满足,消费者能做的就是谨慎选择、找准时机、注意捡漏及多种方式搭配。在巨大的需求之下,抢票软件和其商机也将长期存在,但套路不是长久之计,真正为用户提供价值才能让人继续买单。 抢票是一门玄学 自2019年12月12日进入春运以来,“我在XX抢票,快来帮我加速。皮皮虾,我们抢”、“为我回家助把力”、“你不点我不点,小X回家有危险”的文案又开始出现在各大微信群,为抢票助力和“砍一刀”都成了大家考验人缘的方式。 尽管不久前12306对外表示已经屏蔽了多个抢票软件,但燃财经了解到,智行火车票、高铁管家、携程、美团、飞猪、去哪儿、同城艺龙等60多家平台仍然推出了抢票功能。 不过,这一次,用户的反馈不同以往,结合论坛中网友的反馈和燃财经的采访情况,大家普遍反映“这届抢票软件不行”,即便用了加速包、买了VIP会员还是抢不到票,这也引发了大家对于春运抢票加速包是“真有用”还是“智商税”的讨论。 用户小黎告诉燃财经,他在智行火车票上预约了春节回家的火车票,放票时间一到,抢票软件一直显示“抢票中”但并没有成功。心急之下,他自己登上12306官网,发现显示还有余票,很顺利就买上了。“我怀疑不买加速包,抢票软件是不是根本就不给抢。” 另一位用户张宇在智行火车票、携程、美团都提交了抢票订单并购买了40元极速抢票服务,连续抢了三天仍然没有抢到北京到日照的车票。她表示,前几年用抢票软件都能挺顺利抢到,这一次有点失望。 “这两天我用飞猪抢票,加了30元手续费。从放票开始,我就一直守在手机、电脑前。结果飞猪软件里一直显示无票。我又去贴吧看,发现有人在12306官网买到票了,但飞猪还是显示无票。花了30元的VIP手续费,自始至终没看见显示有票,还不如免费抢票软件。”某网友感叹。 抢票软件套路多 尽管抢票软件的效果不能保证,但套路还不少。 燃财经体验了智行火车票、携程、美团、飞猪等平台的抢票后发现,各大平台的抢票方式大同小异,总体感受是不用加速包、不买VIP基本抢不到票,但买了也不承诺能抢到。因为各平台的规则不透明,没有一家承诺100%抢到票,只会提供预估成功率,而这个成功率到底是70%还是98%,在用户端感知不到差异。 总结来看,抢票软件大致有以下几种套路。 首先是用不明显的字体颜色诱使用户购买“加速包”或VIP会员。如下图携程和美团的购票页面上,要购买加速包的“极速购票”用红色字体,不用加钱的“低速抢票”则是不明显的浅灰色字体,不仔细看的用户有可能不小心勾选付费极速抢票的选项。燃财经在测试时,就差点没找到免费的抢票选项。 另外,在文案上制造焦虑也是常见的方式。“低速抢票难度很高,很可能失败”、“低速度抢票成功率52.2%,极速抢票成功率68.86”、“52%的加速用户选择光速抢票”等提示,很容易给用户制造出一种不用加速包、不花钱就抢不到票的焦虑。 第三,平台会不断提醒用户升级加速包,用上了抢票软件就开始一步一步走入它们的套路中。 抢票软件的抢票速度分为低速、快速、高速、极速、光速、VIP,如果你先选择了低速的免费抢票,系统会显示“邀请好友来助力,最高升至光速抢票”,此时,邀请好友点击助力、看广告就是平台的用意。 而当票没抢到时,页面上会有多个提示你升级的选项,燃财经尝试在各平台上都选择了40元极速抢票,本以为高枕无忧了,没想到这才是个开始。如携程还设置了“优先出票特权:发现余票将优先为你出票,10元/人”、“开通超级会员,免费升级VIP抢票,88元/年”,燃财经计算发现,如果直接开通超级会员需要88元,而一步一步升级到抢票顶配,预计需要加138元。 在美团上选择了40元极速抢票后,系统提醒还差10分加速包升至光速抢票,成功率59%,10元/人,VIP抢票成功率61%,30元/人,想升级到顶配需要80元。智行火车票显示从低速到中速、快速、高速、极速、VIP分别需要10元、20元、30元、40元、50元。 另外,去哪儿旅行上还有“安心抢”、“请朋友帮我挂机”、“购买抢票年卡,72元享3次VIP抢票”等选项,而邀请朋友助力时,软件会获取用户的位置、手机号等信息。 最后,尽管有一些抢票软件承诺抢不到票全额退款,但抢票软件会提示用户勾选更多车次、更多时间、跨站抢票以提升抢票成功概率,最终用户买到的并不是“最优选”,但也无法退费。 以上这些套路也是用户吐槽投诉的重灾区。黑猫投诉上有152条关于抢票软件的投诉,例如“智行火车票二次收费”、“同城艺龙购票98%的成功率却抢不到票”、“高铁管家强制套餐消费”等,多是抢票软件诱导消费、退费难的问题。 众多抢票软件的存在,事实上提高了所有人的抢票门槛。这些五花八门的加速选项,增加消费者的筛选成本,抢到了是运气,抢不到只好自认倒霉。 另外,不少APP存在个人信息泄露的风险。抢票软件作为一个工具类插件,技术开发上的门槛较低,用户输入12306的网站用户名、密码等个人信息被传到平台服务器后,如果安全保护性太低,个人信息很容易被泄露。 抢票软件等于外挂 能不能抢到是概率 抢票软件的加速包真的有效果吗,背后的技术原理又是什么呢? 径点科技首席架构师张英辉告诉燃财经:“我们去12306买票的时候要输入信息、查询、购买,所有的抢票软件都是基于同一种原理,将这些手动操作的步骤用程序来实现,然后不停重试。在用户手速和刷票频率的局限下,第三方抢票平台利用机器刷票、全自动化处理有其优势。” 他还提到,购买了加速包或VIP的不同之处在于,刷新的频率可能会从30秒一次变成10秒一次或5秒一次,或者多个服务器同时抢票。因为消费者大多使用的是普通4G以及20M光纤宽带,跟平台使用的企业级宽带的网速自然是不能相比的,在这个拼速度的模式里,抢票软件集合了企业宽带和机器速度的“代购”,就相当于打游戏的时候加了外挂。 整体来看,刷得越勤,用的服务器越多,抢中票的概率越大,但在实际操作中能不能刷中,可能要看那一秒的时间窗口。“因为市面上有60多个刷票软件,某一趟车从一个站到另外一个站的余票情况随时都在变,这种情况下,谁能刷中不一定,取决于刚好出票这一秒哪个软件在刷。”张英辉强调,抢票软件并不能增加车票,12306系统上没票的时候,再多的加速包都没用。 这个过程中还有12306和抢票软件之间的攻防博弈战。 张英辉指出,从技术上来说,12306后台能检测出刷票软件,如果刷票带来的负担超过网站的负荷,后台通常会限制这样的账号,同一IP地址刷票过于频繁或同一购买请求提交过于频繁,都有可能被拖入慢速或被屏蔽掉。但至于具体是什么限流规则,是由12306来制定、调整和实施。 当然,被屏蔽后的刷票软件可能会通过更换IP地址、使用多台服务器轮流操作等方式规避检测。刷票软件也在持续研究怎样绕过官方规则,双方在不停地博弈。所以用户用抢票软件没买到票,可能是因为没刷到,也可能是刷票软件被屏蔽了。 中国铁道科学研究院12306技术部主任单杏花在2019年接受媒体采访时表示,12306已经对第三方抢票软件的相关特征进行识别并实施了流量拦截,即使用户花钱购买了第三方抢票平台的加速服务,购票的成功率也会大打折扣。另外,12306已经推出了“官方抢票”的候补功能,如果遇到有旅客退签返回的车票,或者是铁路方面根据列车能力情况加挂而增加的车票,就可以优先配给已经排队等候的人。 “刷票软件本身的技术难度不大,市面上甚至有很多免费刷票程序或源代码,稍微懂点的人自己都能安装刷票,但要想把刷票功能做得强大很难。要支持大量用户的需求,又要避开12306的监管,可能就需要投入更多的服务器、人力。说白了,给一个人低速刷票很容易,给100万人快速刷票就会变得复杂。”另一位技术人士李元表示。 从理论上说,平台需要投入设备、人力,完成抢票工作后,收取额外的资源占用费是合理的。张英辉认为,问题在于抢票软件在提高概率的同时也提高了买票者的心理预期,一些花了钱没有达到目的的人就会有负面反馈。用户期望交了钱就买到票,但这明显是个概率模式,必然会出现有的刷得到、有的没刷到的情况。 抢票难题和抢票软件将长期存在 经常有人说,微信几亿人同时在用,双11的时候淘宝那么大的流量都能正常运转,12306为啥连个买票软件都做不好? 张英辉解释,12306的业务逻辑要远远比微信和淘宝复杂得多,比如一辆列车经过,中间是十几个站,不停地有人下有人上,还有人换乘,之间有几百种可能性,系统库存随时在变。如果微信有一条消息没发出去或者发了两次是小事,但一张票如果卖给了两个人,这是重大失误。 另外,12306的库存变化又受到网站、APP、售票厅、自动售票机等多方的实时变动影响,用户需求又有时间、车次、地点的无数种排列组合情况,且整个路程在短时间内就要完成,还要验证用户身份以排除同一车次同一人的重复购买,市面上的众多抢票软件还增加了12306的数据压力,系统无论从技术的完整性和资源调度上都远远比微信和淘宝的业务复杂得多。 他还指出,12306最开始采购的应用可能能够支撑平时1亿人访问,但是到了春节期间,有几亿人同时访问,后台需要采购的设备也不是一时就能实现的,购买、部署、调试等整个周期环节就很长,但春节以后又没有那么大的流量了,硬件折旧损耗,人力维护成本都会浪费,所以12306如果只是为了春运和几个大的节假日去加技术和硬件,实际上也是不可行的。 说到底,铁路总运力是一定的,春运这个非常态的需求是极其巨大的,抢票软件并不能增加供给,也不会提高整体买到票的概率,抢票难的根本原因是供求关系不平衡。 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 阿里云开发者社区

茶什i 2020-01-08 11:53:49 0 浏览量 回答数 0

回答

前言概述 本文介绍了使用函数计算部署深度学习 AI 推理的最佳实践, 其中包括使用 FUN 工具一键部署安装第三方依赖、一键部署、本地调试以及压测评估, 全方位展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。 1.1 DEMO 概述 image 通过上传一个猫或者狗的照片, 识别出这个照片里面的动物是猫还是狗 DEMO 示例效果入口: http://sz.mofangdegisn.cn DEMO 示例工程地址: https://github.com/awesome-fc/cat-dog-classify 开通服务 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 1.2 解决方案 image 如上图所示, 当多个用户通过对外提供的 url 访问推理服务时候,每秒的请求几百上千都没有关系, 函数计算平台会自动伸缩, 提供足够的执行实例来响应用户的请求, 同时函数计算提供了完善的监控设施来监控您的函数运行情况。 1.3. Serverless 方案与传统自建服务方案对比 1.3.1 卓越的工程效率 自建服务 函数计算 Serverless 基础设施 需要用户采购和管理 无 开发效率 除了必要的业务逻辑开发,需要自己建立相同线上运行环境, 包括相关软件的安装、服务配置、安全更新等一系列问题 只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署 学习上手成本 可能使用 K8S 或弹性伸缩( ESS ),需要了解更多的产品、名词和参数的意义 会编写对应的语言的函数代码即可 1.3.2 弹性伸缩免运维 自建服务 函数计算 Serverless 弹性高可用 需要自建负载均衡 (SLB),弹性伸缩,扩容缩容速度较 FC 慢 FC系统固有毫秒级别弹性伸缩,快速实现底层扩容以应对峰值压力,免运维 监控报警查询 ECS 级别的 metrics 提供更细粒度的函数执行情况,每次访问函数执行的 latency 和日志等, 更加完善的报警监控机制 1.3.3 更低的成本 函数计算 (FC) 固有自动伸缩和负载均衡功能,用户不需要购买负载均衡 (SLB) 和弹性伸缩。 具有明显波峰波谷的用户访问场景(比如只有部分时间段有请求,其他时间甚至没有请求),选择按需付费,只需为实际使用的计算资源付费。 对于明显波峰波谷或者稀疏调用具有低成本优势, 同时还保持了弹性能力,以后业务规模做大以后并没有技术切换成本,同时财务成本增长配合预付费也能保持平滑。 部分请求持续平稳的场景下,可以配合预付费解决按需付费较高单价问题。函数计算成本优化最佳实践文档。 假设有一个在线计算服务,由于是CPU 密集型计算, 因此在这里我们将平均 CPU 利用率作为核心参考指标对成本,以一个月为周期,10台 C5 ECS 的总计算力为例,总的计算量约为 30% 场景下, 各解决方案 CPU 资源利用率使用情况示意图大致如下: image 由上图预估出如下计费模型: 函数计算预付费 3CU 一个月: 246.27 元, 计算能力等价于 ECS 计算型 C5 ECS 计算型 C5 (2vCPU,4GB)+云盘: 包月219 元,按量: 446.4 元 包月10 Mbps 的 SLB: 526.52 元(这里做了一定的流量假设), 弹性伸缩免费 饱和使用下,函数计算按量付费的一台机器成本约为按量付费 C5 ECS 的2 倍 平均CPU使用率 计算费用 SLB 总计 函数计算组合付费 >=80% 738+X(246.273+X) 无 <= 738+X 按峰值预留ECS <=30% 2190(10219) 526.52 >=2716.52 弹性伸缩延迟敏感 <=50% 1314(102193/5) 526.52 >= 1840.52 弹性伸缩成本敏感 <=70% 938.57 (102193/7) 526.52 >= 1465.09 注: 这里假设函数逻辑没有公网下行流量费用, 即使有也是一致的, 这里成本比较暂不参与 延时敏感,当 CPU 利用率大于等于 50% 就需要开始进行扩容,不然更来不及应对峰值 成本敏感,当 CPU 利用率大约 80% 即开始进行扩容, 能容受一定几率的超时或者5XX 上表中, 其中函数计算组合付费中的 X 为按需付费的成本价,假设按需付费的计算量占整个计算量的 10%,假设 CPU 利用率为100%, 对应上表,那么需要 3 台 ECS 的计算能力即可。因此 FC 按量付费的成本 X = 3 ️ 446.4 ️ 10% ️ 2 = 267.84 ( FC 按量付费是按量 ECS 的2倍),这个时候函数计算组合付费总计 1005.8 元。 在这个模型预估里面, 只要 FC 按量付费占整个计算量小于 20%, 即使不考虑 SLB, 单纯考虑计算成本, 都是有一定优势的。 1.3.4. 小结 基于函数计算进行 AI 推理等 CPU 密集型的主要优势: 上手简单, 只专注业务逻辑开发, 极大提高工程开发效率。 自建方案有太多学习和配置成本,如针对不同场景,ESS 需要做各种不同的参数配置 系统环境的维护升级等 免运维,函数执行级别粒度的监控和告警。 毫秒级弹性扩容,保证弹性高可用,同时能覆盖延迟敏感和成本敏感类型。 在 CPU 密集型的计算场景下, 通过设置合理的组合计费模式, 在如下场景中具有成本优势: 请求访问具有明显波峰波谷, 其他时间甚至没有请求 有一定稳定的负载请求, 但是有部分时间段请求量突变剧烈 打包代码ZIP包和部署函数 FUN 操作简明视频教程 开通服务 免费开通函数计算, 按量付费,函数计算有很大的免费额度。 免费开通文件存储服务NAS, 按量付费 2.1 安装第三方包到本地并上传到NAS 2.1.1 安装最新的Fun 安装版本为8.x 最新版或者10.x 、12.x nodejs 安装 funcraf 2.1.2 Clone 工程 & Fun 一键安装第三方库到本地 git clone https://github.com/awesome-fc/cat-dog-classify.git 复制 .env_example 文件为 .env, 并且修改 .env 中的信息为自己的信息 执行 fun install -v, fun 会根据 Funfile 中定义的逻辑安装相关的依赖包 image root@66fb3ad27a4c: ls .fun/nas/auto-default/classify model python root@66fb3ad27a4c: du -sm .fun 697 .fun 根据 Funfile 的定义: 将第三方库下载到 .fun/nas/auto-default/classify/python 目录下 本地 model 目录移到 .fun/nas/auto-default/model 目录下 安装完成后,从这里我们看出, 函数计算引用的代码包解压之后已经达到了 670 M, 远超过 50M 代码包限制, 解决方案是 NAS 详情可以参考: 挂载NAS访问,幸运的是 FUN 工具一键解决了 nas 的配置和文件上传问题。 2.1.3. 将下载的依赖的第三方代码包上传到 NAS fun nas init fun nas info fun nas sync fun nas ls nas://classify:/mnt/auto/ 依次执行这些命令,就将本地中的 .fun/nas/auto-default 中的第三方代码包和模型文件传到 NAS 中, 依次看下这几个命令的做了什么事情: fun nas init: 初始化 NAS, 基于您的 .env 中的信息获取(已有满足条件的nas)或创建一个同region可用的nas fun nas info: 可以查看本地 NAS 的目录位置, 对于此工程是 $(pwd)/.fun/nas/auto-default/classify fun nas sync: 将本地 NAS 中的内容(.fun/nas/auto-default/classify)上传到 NAS 中的 classify 目录 fun nas ls nas:///mnt/auto/: 查看我们是否已经正确将文件上传到了 NAS 登录 NAS 控制台 https://nas.console.aliyun.com 和 VPC 控制台 https://vpc.console.aliyun.com可以观察到在指定的 region 上有 NAS 和相应的 vpc 创建成功 2.2 本地调试函数 在 template.yml 中, 指定了这个函数是 http 类型的函数, 所以根据 fun 的提示: Tips for next step Invoke Event Function: fun local invokeInvoke Http Function: fun local startBuild Http Function: fun buildDeploy Resources: fun deploy 执行 fun local start, 本地就会启动一个 http server 来模拟函数的执行, 然后我们 client 端可以使用 postman, curl 或者浏览器, 比如对于本例: image image 2.3 部署函数到FC平台 本地调试OK 后,我们接下来将函数部署到云平台: 修改 template.yml LogConfig 中的 Project, 任意取一个不会重复的名字即可,有两处地方需要更改,然后执行 fun deploy 注意: template.yml 注释的部分为自定义域名的配置, 如果想在 fun deploy 中完成这个部署工作: 先去域名解析, 比如在示例中, 将域名 sz.mofangdegisn.cn 解析到 123456.cn-hangzhou.fc.aliyuncs.com, 对应的域名、accountId 和 region 修改成自己的 去掉 template.yml 中的注释, 修改成自己的域名 执行 fun deploy 这个时候如果没有自定义域名, 直接通过浏览器访问http trigger 的url, 比如 https://123456.cn-shenzhen.fc.aliyuncs.com/2016-08-15/proxy/classify/cat-dog/ 会被强制下载. 原因:https://help.aliyun.com/knowledge_detail/56103.html#HTTP-Trigger-compulsory-header image 登录控制台https://fc.console.aliyun.com,可以看到service 和函数已经创建成功,并且 service 也已经正确配置。 image 在这里,我们发现第一次打开页面访问函数的时候,执行环境实例冷启动时间非常长, 如果是一个在线AI推理服务,对响应时间非常敏感,冷启动引起的毛刺对于这种类型的服务是不可接受的,接下来,本文讲解如何利用函数计算的预留模式来消除冷启动带来的负面影响。 使用预留模式消除冷启动毛刺 函数计算具有动态伸缩的特性, 根据并发请求量,自动弹性扩容出执行环境来执行环境,在这个典型的深度学习示例中,import keras 消耗的时间很长 , 在我们设置的 1 G 规格的函数中, 并发访问的时候耗时10s左右, 有时甚至20s+ start = time.time() from keras.models import model_from_json print("import keras time = ", time.time()-start) 3.1 函数计算设置预留 预留操作简明视频教程 在 FC 控制台,发布版本,并且基于该版本创建别名 prod,并且基于别名 prod 设置预留, 操作过程请参考:https://help.aliyun.com/document_detail/138103.html 将该函数的 http trigger 和自定义域名的设置执行 prod 版本 image image 一次压测结果 imageimage 从上面图中我们可以看出,当函数执行的请求到来时,优先被调度到预留的实例中被执行, 这个时候是没有冷启动的,所以请求是没有毛刺的, 后面随着测试的压力不断增大(峰值TPS 达到 1184), 预留的实例不能满足调用函数的请求, 这个时候函数计算就自动进行按需扩容实例供函数执行,此时的调用就有冷启动的过程, 从上面我们可以看出,函数的最大 latency 时间甚至达到了 32s,如果这个web AP是延时敏感的,这个 latency 是不可接受的。 总结 函数计算具有快速自动伸缩扩容能力 预留模式很好地解决了冷启动中的毛刺问题 开发简单易上手,只需要关注具体的代码逻辑, Fun 工具助您一键式部署运用 函数计算具有很好监控设施, 您可以可视化观察您函数运行情况, 执行时间、内存等信息

1934890530796658 2020-03-27 18:21:48 0 浏览量 回答数 0

回答

摘要:面试也是一门学问,在面试之前做好充分的准备则是成功的必须条件,而程序员在代码面试时,常会遇到编写算法的相关问题,比如排序、二叉树遍历等等。 在程序员的职业生涯中,算法亦算是一门基础课程,尤其是在面试的时候,很多公司都会让程序员编写一些算法实例,例如快速排序、二叉树查找等等。 本文总结了程序员在代码面试中最常遇到的10大算法类型,想要真正了解这些算法的原理,还需程序员们花些功夫。 1.String/Array/Matrix 在Java中,String是一个包含char数组和其它字段、方法的类。如果没有IDE自动完成代码,下面这个方法大家应该记住: String/arrays很容易理解,但与它们有关的问题常常需要高级的算法去解决,例如动态编程、递归等。 下面列出一些需要高级算法才能解决的经典问题: Evaluate Reverse Polish Notation Longest Palindromic Substring 单词分割 字梯 Median of Two Sorted Arrays 正则表达式匹配 合并间隔 插入间隔 Two Sum 3Sum 4Sum 3Sum Closest String to Integer 合并排序数组 Valid Parentheses 实现strStr() Set Matrix Zeroes 搜索插入位置 Longest Consecutive Sequence Valid Palindrome 螺旋矩阵 搜索一个二维矩阵 旋转图像 三角形 Distinct Subsequences Total Maximum Subarray 删除重复的排序数组 删除重复的排序数组2 查找没有重复的最长子串 包含两个独特字符的最长子串 Palindrome Partitioning 2.链表 在Java中实现链表是非常简单的,每个节点都有一个值,然后把它链接到下一个节点。 class Node { int val; Node next; Node(int x) { val = x; next = null; } } 比较流行的两个链表例子就是栈和队列。 栈(Stack) class Stack{ Node top; public Node peek(){ if(top != null){ return top; } return null; } public Node pop(){ if(top == null){ return null; }else{ Node temp = new Node(top.val); top = top.next; return temp; } } public void push(Node n){ if(n != null){ n.next = top; top = n; } } } 队列(Queue) class Queue{ Node first, last;   public void enqueue(Node n){ if(first == null){ first = n; last = first; }else{ last.next = n; last = n; } }   public Node dequeue(){ if(first == null){ return null; }else{ Node temp = new Node(first.val); first = first.next; return temp; } } } 值得一提的是,Java标准库中已经包含一个叫做Stack的类,链表也可以作为一个队列使用(add()和remove())。(链表实现队列接口)如果你在面试过程中,需要用到栈或队列解决问题时,你可以直接使用它们。 在实际中,需要用到链表的算法有: 插入两个数字 重新排序列表 链表周期 Copy List with Random Pointer 合并两个有序列表 合并多个排序列表 从排序列表中删除重复的 分区列表 LRU缓存 3.树&堆 这里的树通常是指二叉树。 class TreeNode{ int value; TreeNode left; TreeNode right; } 下面是一些与二叉树有关的概念: 二叉树搜索:对于所有节点,顺序是:left children <= current node <= right children; 平衡vs.非平衡:它是一 棵空树或它的左右两个子树的高度差的绝对值不超过1,并且左右两个子树都是一棵平衡二叉树; 满二叉树:除最后一层无任何子节点外,每一层上的所有结点都有两个子结点; 完美二叉树(Perfect Binary Tree):一个满二叉树,所有叶子都在同一个深度或同一级,并且每个父节点都有两个子节点; 完全二叉树:若设二叉树的深度为h,除第 h 层外,其它各层 (1~h-1) 的结点数都达到最大个数,第 h 层所有的结点都连续集中在最左边,这就是完全二叉树。 堆(Heap)是一个基于树的数据结构,也可以称为优先队列( PriorityQueue),在队列中,调度程序反复提取队列中第一个作业并运行,因而实际情况中某些时间较短的任务将等待很长时间才能结束,或者某些不短小,但具有重要性的作业,同样应当具有优先权。堆即为解决此类问题设计的一种数据结构。 下面列出一些基于二叉树和堆的算法: 二叉树前序遍历 二叉树中序遍历 二叉树后序遍历 字梯 验证二叉查找树 把二叉树变平放到链表里 二叉树路径和 从前序和后序构建二叉树 把有序数组转换为二叉查找树 把有序列表转为二叉查找树 最小深度二叉树 二叉树最大路径和 平衡二叉树 4.Graph 与Graph相关的问题主要集中在深度优先搜索和宽度优先搜索。深度优先搜索非常简单,你可以从根节点开始循环整个邻居节点。下面是一个非常简单的宽度优先搜索例子,核心是用队列去存储节点。 第一步,定义一个GraphNode class GraphNode{ int val; GraphNode next; GraphNode[] neighbors; boolean visited; GraphNode(int x) { val = x; } GraphNode(int x, GraphNode[] n){ val = x; neighbors = n; } public String toString(){ return "value: "+ this.val; } } 第二步,定义一个队列 class Queue{ GraphNode first, last; public void enqueue(GraphNode n){ if(first == null){ first = n; last = first; }else{ last.next = n; last = n; } } public GraphNode dequeue(){ if(first == null){ return null; }else{ GraphNode temp = new GraphNode(first.val, first.neighbors); first = first.next; return temp; } } } 第三步,使用队列进行宽度优先搜索 public class GraphTest { public static void main(String[] args) { GraphNode n1 = new GraphNode(1); GraphNode n2 = new GraphNode(2); GraphNode n3 = new GraphNode(3); GraphNode n4 = new GraphNode(4); GraphNode n5 = new GraphNode(5); n1.neighbors = new GraphNode[]{n2,n3,n5}; n2.neighbors = new GraphNode[]{n1,n4}; n3.neighbors = new GraphNode[]{n1,n4,n5}; n4.neighbors = new GraphNode[]{n2,n3,n5}; n5.neighbors = new GraphNode[]{n1,n3,n4}; breathFirstSearch(n1, 5); } public static void breathFirstSearch(GraphNode root, int x){ if(root.val == x) System.out.println("find in root"); Queue queue = new Queue(); root.visited = true; queue.enqueue(root); while(queue.first != null){ GraphNode c = (GraphNode) queue.dequeue(); for(GraphNode n: c.neighbors){ if(!n.visited){ System.out.print(n + " "); n.visited = true; if(n.val == x) System.out.println("Find "+n); queue.enqueue(n); } } } } } 输出结果: value: 2 value: 3 value: 5 Find value: 5 value: 4 实际中,基于Graph需要经常用到的算法: 克隆Graph 15 2014-04-24 18:55:03回复数 293 只看楼主 引用 举报 楼主 柔软的胖纸 Bbs1 5.排序 不同排序算法的时间复杂度,大家可以到wiki上查看它们的基本思想。 BinSort、Radix Sort和CountSort使用了不同的假设,所有,它们不是一般的排序方法。 下面是这些算法的具体实例,另外,你还可以阅读:Java开发者在实际操作中是如何排序的。 归并排序 快速排序 插入排序 6.递归和迭代 下面通过一个例子来说明什么是递归。 问题: 这里有n个台阶,每次能爬1或2节,请问有多少种爬法? 步骤1:查找n和n-1之间的关系 为了获得n,这里有两种方法:一个是从第一节台阶到n-1或者从2到n-2。如果f(n)种爬法刚好是爬到n节,那么f(n)=f(n-1)+f(n-2)。 步骤2:确保开始条件是正确的 f(0) = 0; f(1) = 1; public static int f(int n){ if(n <= 2) return n; int x = f(n-1) + f(n-2); return x; } 递归方法的时间复杂度指数为n,这里会有很多冗余计算。 f(5) f(4) + f(3) f(3) + f(2) + f(2) + f(1) f(2) + f(1) + f(2) + f(2) + f(1) 该递归可以很简单地转换为迭代。 public static int f(int n) { if (n <= 2){ return n; } int first = 1, second = 2; int third = 0; for (int i = 3; i <= n; i++) { third = first + second; first = second; second = third; } return third; } 在这个例子中,迭代花费的时间要少些。关于迭代和递归,你可以去 这里看看。 7.动态规划 动态规划主要用来解决如下技术问题: 通过较小的子例来解决一个实例; 对于一个较小的实例,可能需要许多个解决方案; 把较小实例的解决方案存储在一个表中,一旦遇上,就很容易解决; 附加空间用来节省时间。 上面所列的爬台阶问题完全符合这四个属性,因此,可以使用动态规划来解决: public static int[] A = new int[100]; public static int f3(int n) { if (n <= 2) A[n]= n; if(A[n] > 0) return A[n]; else A[n] = f3(n-1) + f3(n-2);//store results so only calculate once! return A[n]; } 一些基于动态规划的算法: 编辑距离 最长回文子串 单词分割 最大的子数组 8.位操作 位操作符: 从一个给定的数n中找位i(i从0开始,然后向右开始) public static boolean getBit(int num, int i){ int result = num & (1<<i); if(result == 0){ return false; }else{ return true; } } 例如,获取10的第二位: i=1, n=10 1<<1= 10 1010&10=10 10 is not 0, so return true; 典型的位算法: Find Single Number Maximum Binary Gap 9.概率 通常要解决概率相关问题,都需要很好地格式化问题,下面提供一个简单的例子: 有50个人在一个房间,那么有两个人是同一天生日的可能性有多大?(忽略闰年,即一年有365天) 算法: public static double caculateProbability(int n){ double x = 1; for(int i=0; i<n; i++){ x *= (365.0-i)/365.0; } double pro = Math.round((1-x) * 100); return pro/100; } 结果:calculateProbability(50) = 0.97 10.组合和排列 组合和排列的主要差别在于顺序是否重要。 例1: 1、2、3、4、5这5个数字,输出不同的顺序,其中4不可以排在第三位,3和5不能相邻,请问有多少种组合? 例2: 有5个香蕉、4个梨、3个苹果,假设每种水果都是一样的,请问有多少种不同的组合? 基于它们的一些常见算法 排列 排列2 排列顺序 来自: ProgramCreek 转载于:https://bbs.csdn.net/topics/390768965

养狐狸的猫 2019-12-02 02:11:29 0 浏览量 回答数 0

回答

PHP面试干货 1、进程和线程 进程和线程都是由操作系统所体会的程序运行的基本单元,系统利用该基本单元实现系统对应用的并发性。进程和线程的区别在于: 简而言之,一个程序至少有一个进程,一个进程至少有一个线程. 线程的划分尺度小于进程,使得多线程程序的并发性高。 另外,进程在执行过程中拥有独立的内存单元,而多个线程共享内存,从而极大地提高了程序的运行效率。 线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行,必须依存在应用程序中,由应用程序提供多个线程执行控制。 从逻辑角度来看,多线程的意义在于一个应用程序中,有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用,来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。 2、apache默认使用进程管理还是线程管理?如何判断并设置最大连接数? 一个进程可以开多个线程 默认是进程管理 默认有一个主进程 Linux: ps -aux | grep httpd | more 一个子进程代表一个用户的连接 Conf/extra/httpd-mpm.conf 多路功能模块 http -l 查询当前apache处于什么模式下 3、单例模式 单例模式需求:只能实例化产生一个对象 如何实现: 私有化构造函数 禁止克隆对象 提供一个访问这个实例的公共的静态方法(通常为getInstance方法),从而返回唯一对象 需要一个保存类的静态属性 class demo { private static $MyObject; //保存对象的静态属性 private function __construct(){ //私有化构造函数 } private function __clone(){ //禁止克隆 } public static function getInstance(){ if(! (self::$MyObject instanceof self)){ self::$MyObject = new self; } return self::$MyObject; } } 4、安装完Apache后,在http.conf中配置加载PHP文件以Apache模块的方式安装PHP,在文件http.conf中首先要用语句LoadModule php5_module "e:/php/php5apache2.dll"动态装载PHP模块,然后再用语句AddType application/x-httpd-php .php 使得Apache把所有扩展名为PHP的文件都作为PHP脚本处理 5、debug_backtrace()函数能返回脚本里的任意行中调用的函数的名称。该函数同时还经常被用在调试中,用来判断错误是如何发生的 function one($str1, $str2) { two("Glenn", "Quagmire"); } function two($str1, $str2) { three("Cleveland", "Brown"); } function three($str1, $str2) { print_r(debug_backtrace()); } one("Peter", "Griffin"); Array ( [0] => Array ( [file] => D:\www\test\result.php [line] => 9 [function] => three [args] => Array ( [0] => Cleveland [1] => Brown ) ) [1] => Array ( [file] => D:\www\test\result.php [line] => 5 [function] => two [args] => Array ( [0] => Glenn [1] => Quagmire ) ) [2] => Array ( [file] => D:\www\test\result.php [line] => 16 [function] => one [args] => Array ( [0] => Peter [1] => Griffin ) ) ) 6、输出用户的IP地址,并且判断用户的IP地址是否在192.168.1.100 — 192.168.1.150之间 echo $ip=getenv('REMOTE_ADDR'); $ip=str_replace('.','',$ip); if($ip<1921681150 && $ip>1921681100) { echo 'ip在192.168.1.100—–192.168.1.150之间'; } else { echo 'ip不在192.168.1.100—–192.168.1.150之间'; } 7、请将2维数组按照name的长度进行重新排序,按照顺序将id赋值 $tarray = array( array('id' => 0, 'name' => '123'), array('id' => 0, 'name' => '1234'), array('id' => 0, 'name' => '1235'), array('id' => 0, 'name' => '12356'), array('id' => 0, 'name' => '123abc') ); foreach($tarray as $key=>$val) { $c[]=$val['name']; } function aa($a,$b) { if(strlen($a)==strlen($b)) return 0; return strlen($a)>strlen($b)?-1:1; } usort($c,'aa'); $len=count($c); for($i=0;$i<$len;$i++) { $t[$i]['id']=$i+1; $t[$i]['name']=$c[$i]; } print_r($t); 8、表单数据提交方式POST和GET的区别,URL地址传递的数据最大长度是多少? POST方式提交数据用户不可见,是数据更安全,最大长度不受限制,而GET方式传值在URL地址可以看到,相对不安全,对大长度是2048字节。 9、SESSION和COOKIE的作用和区别,SESSION信息的存储方式,如何进行遍历 SESSION和COOKIE都能够使值在页面之间进行传递,SESSION存储在服务器端,数据更安全,COOKIE保存在客户端,用户使用手段可以进行修改,SESSION依赖于COOKIE进行传递的。Session遍历使用$_SESSION[]取值,cookie遍历使用$_COOKIE[]取值。 10、什么是数据库索引,主键索引,唯一索引的区别,索引的缺点是什么 索引用来快速地寻找那些具有特定值的记录。 主键索引和唯一索引的区别:主键是一种唯一性索引,但它必须指定为“PRIMARY KEY”,每个表只能有一个主键。唯一索引索引列的所有值都只能出现一次,即必须唯一。 索引的缺点: 1、创建索引和维护索引要耗费时间,这种时间随着数据量的增加而增加。 2、索引需要占用物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,需要的空间就会更大。 3、当对表中的数据进行增加、删除、修改的时候,索引也要动态的维护,这样就降低了数据的维护速度。 11、数据库设计时,常遇到的性能瓶颈有哪些,常有的解决方案 瓶颈主要有: 1、磁盘搜索 优化方法是:将数据分布在多个磁盘上 2、磁盘读/写 优化方法是:从多个磁盘并行读写。 3、CPU周期 优化方法:扩充内存 4、内存带宽 12、include和require区别 include引入文件的时候,如果碰到错误,会给出提示,并继续运行下边的代码。 require引入文件的时候,如果碰到错误,会给出提示,并停止运行下边的代码。 13、文件上传时设计到点 和文件上传有关的php.ini配置选项(File Uploads): file_uploads=On/Off:文件是否允许上传 upload_max_filesize上传文件时,单个文件的最大大小 post_max_size:提交表单时,整个post表单的最大大小 max_file_uploads =20上传文件的个数 内存占用,脚本最大执行时间也间接影响到文件的上传 14、header常见状态 //200 正常状态 header('HTTP/1.1 200 OK'); // 301 永久重定向,记得在后面要加重定向地址 Location:$url header('HTTP/1.1 301 Moved Permanently'); // 重定向,其实就是302 暂时重定向 header('Location: http://www.maiyoule.com/'); // 设置页面304 没有修改 header('HTTP/1.1 304 Not Modified'); // 显示登录框, header('HTTP/1.1 401 Unauthorized'); header('WWW-Authenticate: Basic realm="登录信息"'); echo '显示的信息!'; // 403 禁止访问 header('HTTP/1.1 403 Forbidden'); // 404 错误 header('HTTP/1.1 404 Not Found'); // 500 服务器错误 header('HTTP/1.1 500 Internal Server Error'); // 3秒后重定向指定地址(也就是刷新到新页面与 <meta http-equiv="refresh" content="10;http://www.maiyoule.com/ /> 相同) header('Refresh: 3; url=http://www.maiyoule.com/'); echo '10后跳转到http://www.maiyoule.com'; // 重写 X-Powered-By 值 header('X-Powered-By: PHP/5.3.0'); header('X-Powered-By: Brain/0.6b'); //设置上下文语言 header('Content-language: en'); // 设置页面最后修改时间(多用于防缓存) $time = time() - 60; //建议使用filetime函数来设置页面缓存时间 header('Last-Modified: '.gmdate('D, d M Y H:i:s', $time).' GMT'); // 设置内容长度 header('Content-Length: 39344'); // 设置头文件类型,可以用于流文件或者文件下载 header('Content-Type: application/octet-stream'); header('Content-Disposition: attachment; filename="example.zip"'); header('Content-Transfer-Encoding: binary'); readfile('example.zip');//读取文件到客户端 //禁用页面缓存 header('Cache-Control: no-cache, no-store, max-age=0, must-revalidate'); header('Expires: Mon, 26 Jul 1997 05:00:00 GMT'); header('Pragma: no-cache'); //设置页面头信息 header('Content-Type: text/html; charset=iso-8859-1'); header('Content-Type: text/html; charset=utf-8'); header('Content-Type: text/plain'); header('Content-Type: image/jpeg'); header('Content-Type: application/zip'); header('Content-Type: application/pdf'); header('Content-Type: audio/mpeg'); header('Content-Type: application/x-shockwave-flash'); //.... 至于Content-Type 的值 可以去查查 w3c 的文档库,那里很丰富 15、ORM和ActiveRecord ORM:object relation mapping,即对象关系映射,简单的说就是对象模型和关系模型的一种映射。为什么要有这么一个映射?很简单,因为现在的开发语言基本都是oop的,但是传统的数据库却是关系型的。为了可以靠贴近面向对象开发,我们想要像操作对象一样操作数据库。还可以隔离底层数据库层,我们不需要关心我们使用的是mysql还是其他的关系型数据库 ActiveRecord也属于ORM层,由Rails最早提出,遵循标准的ORM模型:表映射到记录,记录映射到对象,字段映射到对象属性。配合遵循的命名和配置惯例,能够很大程度的快速实现模型的操作,而且简洁易懂。 ActiveRecord的主要思想是: 1. 每一个数据库表对应创建一个类,类的每一个对象实例对应于数据库中表的一行记录;通常表的每个字段在类中都有相应的Field; 2. ActiveRecord同时负责把自己持久化,在ActiveRecord中封装了对数据库的访问,即CURD;; 3. ActiveRecord是一种领域模型(Domain Model),封装了部分业务逻辑; ActiveRecord比较适用于: 1. 业务逻辑比较简单,当你的类基本上和数据库中的表一一对应时, ActiveRecord是非常方便的,即你的业务逻辑大多数是对单表操作; 2. 当发生跨表的操作时, 往往会配合使用事务脚本(Transaction Script),把跨表事务提升到事务脚本中; 3. ActiveRecord最大优点是简单, 直观。 一个类就包括了数据访问和业务逻辑. 如果配合代码生成器使用就更方便了; 这些优点使ActiveRecord特别适合WEB快速开发。 16、斐波那契方法,也就是1 1 2 3 5 8 ……,这里给出两种方法,大家可以对比下,看看哪种快,以及为什么 function fibonacci($n){ if($n == 0){ return 0; } if($n == 1){ return 1; } return fibonacci($n-1)+fibonacci($n-2); } function fibonacci($n){ for($i=0; $i<$n; $i++){ $r[] = $i<2 ? 1 : $r[$i-1]+$r[$i-2]; } return $r[--$i]; } 17、约瑟夫环,也就是常见的数猴子,n只猴子围成一圈,每只猴子下面标了编号,从1开始数起,数到m那么第m只猴子便退出,依次类推,每数到m,那么那个位置的猴子退出,那么最后剩下的猴子下的编号是啥。 function yuesefu($n,$m) { $r=0; for($i=2; $i<=$n; $i++) { $r=($r+$m)%$i; } return $r+1; } 18、冒泡排序,大致是临近的数字两两进行比较,按照从小到大或者从大到小的顺序进行交换,这样一趟过去后,最大或最小的数字被交换到了最后一位,然后再从头开始进行两两比较交换,直到倒数第二位时结束 function bubbleSort($arr){ for($i=0, $len=count($arr); $i<$len; $i++){ for($j=0; $j<$len; $j++){ if($arr[$i]<$arr[$j]){ $tmp = $arr[$j]; $arr[$j] = $arr[$i]; $arr[$i] = $tmp; } } } return $arr; } 19、快速排序,也就是找出一个元素(理论上可以随便找一个)作为基准,然后对数组进行分区操作,使基准左边元素的值都不大于基准值,基准右边的元素值 都不小于基准值,如此作为基准的元素调整到排序后的正确位置。递归快速排序,将其他n-1个元素也调整到排序后的正确位置。最后每个元素都是在排序后的正 确位置,排序完成。所以快速排序算法的核心算法是分区操作,即如何调整基准的位置以及调整返回基准的最终位置以便分治递归。 function quickSort($arr){ $len = count($arr); if($len <=1){ return $arr; } $key = $arr[0]; $leftArr = $rightArr= array(); for($i=1; $i<$len; $i++){ if($arr[$i] <= $key){ $leftArr[] = $arr[$i]; } else{ $rightArr[] = $arr[$i]; } } $leftArr = quickSort($leftArr); $rightArr = quickSort($rightArr); return array_merge($leftArr, array($key), $rightArr); } 20、(递归的)列出目录下所有文件及目录,这里也有两种方法 function listDir($path){ $res = dir($path); while($file = $res->read()){ if($file == '.' || $file == '..'){ continue; } if(is_dir($path . '/' .$file)){ echo $path . '/' .$file . "\r\n"; listDir($path . '/' .$file); } else{ echo $path . '/' .$file . "\r\n"; } } $res->close(); } function listDir($path){ if(is_dir($path)){ if(FALSE !== ($res = opendir($path))){ while(FALSE !== ($file = readdir($res))){ if($file == '.' || $file == '..'){ continue; } $subPath = $path . '/' . $file; if(is_dir($subPath)){ echo $subPath . "\r\n"; listDir($subPath); } else{ echo $subPath . "\r\n"; } } } } } 21、找出相对的目录,比如/a/b/c/d/e.php相对于/a/b/13/34/c.php是/c/d/ function ralativePath($a, $b){ $a = explode('/', dirname($a)); $b = explode('/', dirname($b)); $c = '/'; foreach ($a as $k=> $v){ if($v != $b[$k]){ $c .= $v . '/'; } } echo $c; } 22、快速找出url中php后缀 function get_ext($url){ $data = parse_url($url); return pathinfo($data['path'], PATHINFO_EXTENSION); } 23、正则题,使用正则抓取网页,以网页meta为utf8为准,若是抓取的网页编码为big5之类的,需要转化为utf8再收录 function preg_meta($meta){ $replacement = "\\1utf8\\6\\7"; $pattern = '#(<meta\s+http-equiv=(\'|"|)Content-Type(\'|"|)\s+content=(\'|"|)text/html; charset=)(\w+)(\'|"|)(>)#i'; return preg_replace($pattern, $replacement, $meta); } echo preg_meta("<meta http-equiv=Content-Type content='text/html; charset=big5'><META http-equiv=\"Content-Type\" content='text/html; charset=big5'>"); 24、不用php的反转函数倒序输出字符串,如abc,反序输出cba function revstring($str){ for($i=strlen($str)-1; $i>=0; $i--){ echo $str{$i}; } } revstring('abc'); 25、常见端口 TCP 21端口:FTP 文件传输服务 SSH 22端口:SSH连接linux服务器,通过SSH连接可以远程管理Linux等设备 TCP 23端口:TELNET 终端仿真服务 TCP 25端口:SMTP 简单邮件传输服务 UDP 53端口:DNS 域名解析服务 TCP 80端口:HTTP 超文本传输服务 TCP 110端口:POP3 “邮局协议版本3”使用的端口 TCP 443端口:HTTPS 加密的超文本传输服务 TCP 1521端口:Oracle数据库服务 TCP 1863端口:MSN Messenger的文件传输功能所使用的端口 TCP 3389端口:Microsoft RDP 微软远程桌面使用的端口 TCP 5631端口:Symantec pcAnywhere 远程控制数据传输时使用的端口 UDP 5632端口:Symantec pcAnywhere 主控端扫描被控端时使用的端口 TCP 5000端口:MS SQL Server使用的端口 UDP 8000端口:腾讯QQ 26、linux常用的命令 top linux进程实时监控 ps 在Linux中是查看进程的命令。ps查看正处于Running的进程 mv 为文件或目录改名或将文件由一个目录移入另一个目录中。 find 查找文件 df 可显示所有文件系统对i节点和磁盘块的使用情况。 cat 打印文件类容 chmod 变更文件或目录的权限 chgrp 文件或目录的权限的掌控以拥有者及所诉群组来管理。可以使用chgrp指令取变更文件与目录所属群组 grep 是一种强大的文本搜索工具,它能使用正则表达式搜索文本,并把匹 配的行打印出来。 wc 为统计指定文件中的字节数、字数、行数,并将统计结果显示输出 27、对于大流量的网站,您采用什么样的方法来解决访问量问题 首先,确认服务器硬件是否足够支持当前的流量 其次,优化数据库访问。 第三,禁止外部的盗链。 第四,控制大文件的下载。 第五,使用不同主机分流主要流量 第六,使用流量分析统计软件 28、$_SERVER常用的字段 $_SERVER['PHP_SELF'] #当前正在执行脚本的文件名 $_SERVER['SERVER_NAME'] #当前运行脚本所在服务器主机的名称 $_SERVER['REQUEST_METHOD'] #访问页面时的请求方法。例如:“GET”、“HEAD”,“POST”,“PUT” $_SERVER['QUERY_STRING'] #查询(query)的字符串 $_SERVER['HTTP_HOST'] #当前请求的 Host: 头部的内容 $_SERVER['HTTP_REFERER'] #链接到当前页面的前一页面的 URL 地址 $_SERVER['REMOTE_ADDR'] #正在浏览当前页面用户的 IP 地址 $_SERVER['REMOTE_HOST'] #正在浏览当前页面用户的主机名 $_SERVER['SCRIPT_FILENAME'] #当前执行脚本的绝对路径名 $_SERVER['SCRIPT_NAME'] #包含当前脚本的路径。这在页面需要指向自己时非常有用 $_SERVER['REQUEST_URI'] #访问此页面所需的 URI。例如,“/index.html” 29、安装php扩展 进入扩展的目录 phpize命令得到configure文件 ./configure --with-php-config=/usr/local/php/bin/php-config make & make install 在php.ini中加入扩展名称.so 重启web服务器(nginx/apache) 30、php-fpm与nginx PHP-FPM也是一个第三方的FastCGI进程管理器,它是作为PHP的一个补丁来开发的,在安装的时候也需要和PHP源码一起编译,也就是说PHP-FPM被编译到PHP内核中,因此在处理性能方面更加优秀;同时它在处理高并发方面也比spawn-fcgi引擎好很多,因此,推荐Nginx+PHP/PHP-FPM这个组合对PHP进行解析。 FastCGI 的主要优点是把动态语言和HTTP Server分离开来,所以Nginx与PHP/PHP-FPM经常被部署在不同的服务器上,以分担前端Nginx服务器的压力,使Nginx专一处理静态请求和转发动态请求,而PHP/PHP-FPM服务器专一解析PHP动态请求 #fastcgi FastCGI是一个可伸缩地、高速地在HTTP server和动态脚本语言间通信的接口。多数流行的HTTP server都支持FastCGI,包括Apache、Nginx和lighttpd等,同时,FastCGI也被许多脚本语言所支持,其中就有PHP。 FastCGI是从CGI发展改进而来的。传统CGI接口方式的主要缺点是性能很差,因为每次HTTP服务器遇到动态程序时都需要重新启动脚本解析器来执行解析,然后结果被返回给HTTP服务器。这在处理高并发访问时,几乎是不可用的。另外传统的CGI接口方式安全性也很差,现在已经很少被使用了。 FastCGI接口方式采用C/S结构,可以将HTTP服务器和脚本解析服务器分开,同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HTTP服务器每次遇到动态程序时,可以将其直接交付给FastCGI进程来执行,然后将得到的结果返回给浏览器。这种方式可以让HTTP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端,这在很大程度上提高了整个应用系统的性能。 Nginx+FastCGI运行原理 Nginx不支持对外部程序的直接调用或者解析,所有的外部程序(包括PHP)必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket,(这个socket可以是文件socket,也可以是ip socket)。为了调用CGI程序,还需要一个FastCGI的wrapper(wrapper可以理解为用于启动另一个程序的程序),这个wrapper绑定在某个固定socket上,如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候,通过FastCGI接口,wrapper接纳到请求,然后派生出一个新的线程,这个线程调用解释器或者外部程序处理脚本并读取返回数据;接着,wrapper再将返回的数据通过FastCGI接口,沿着固定的socket传递给Nginx;最后,Nginx将返回的数据发送给客户端,这就是Nginx+FastCGI的整个运作过程。 31、ajax全称“Asynchronous Javascript And XML”(异步JavaScript和XML)

小川游鱼 2019-12-02 01:41:29 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 阿里云双十一主会场 阿里云双十一新人会场 1024程序员加油包 阿里云双十一拼团会场 场景化解决方案 阿里云双十一直播大厅