首页 文章 精选 留言 我的

精选列表

搜索[计算机组成原理],共10000篇文章
优秀的个人博客,低调大师

Feign 从注册到调用原理分析

本文主要讲述 Feign 是如何注册到 Spring 容器、融合 Ribbon进行负载均衡、进行 RPC 调用。 简单提一下项目中一般都是如何使用 Feign 的,首先声明一个@FeignClient,定义 RPC 调用方法,然后像调用本地方法一样,调用远程服务的方法 // 定义 FeignClient @FeignClient(value = "service-order",path = "/order") public interface OrderFeignService { @RequestMapping("/findOrderByUserId/{userId}") R findOrderByUserId(@PathVariable("userId") Integer userId); } // 调用远程服务 @Autowired OrderFeignService orderFeignService; R findOrderByUserId(@PathVariable("id") Integer id) { //feign调用 R result = orderFeignService.findOrderByUserId(id); return result; } 这样一来,我们省去了自己去配置 RestTemplate 或其他 HTTPClient 的麻烦,但是简单方便的同时你是否会有一些疑惑: 我们使用@Autowired注入的 OrderFeignService,那么它一定是一个 Spring Bean,它是什么时候,如何被注入到 Spring 容器的? Feign 是如何执行 findOrderByUserId()的? @RequestMapping 是 SpringMVC 的注解呀,怎么在 Feign 中也会生效呢? Feign 是如何整合 Ribbon 的? Ribbon 是如何获取注册中心的服务的? Ribbon 是如何进行负载均衡的? 理解了上面的这些问题,我们也就明白了 Feign 是如何进行调用的,那么带着这些问题我们来一步步分析 @FeignClient 注册 @EnableFeignClients 注解 根据 SpringBoot 自动装配的思想,先猜想下一定会有@Enablexxx ,然后再有@Import(xxx.class),来进行 Feign 的自动注入 要使用 Feign 首先要引入 Feign 的 Maven 依赖,接着一定要在启动类上添加注解 @EnableFeignClients 2.@EnableFeignClients @Import(FeignClientsRegistrar.class) 3.注册 @FeignClient public void registerBeanDefinitions(AnnotationMetadata metadata, BeanDefinitionRegistry registry) { // 注册 Feign 配置信息 registerDefaultConfiguration(metadata, registry); // 注册 @FeignClient registerFeignClients(metadata, registry); } 扫描并注册 FeignClient 为 BeanDefinition public void registerFeignClients(AnnotationMetadata metadata, BeanDefinitionRegistry registry) { // ...,省略了部分源码 扫描所有 @FeignClient 标注的类 Map<String, Object> attrs = metadata .getAnnotationAttributes(EnableFeignClients.class.getName()); AnnotationTypeFilter annotationTypeFilter = new AnnotationTypeFilter( FeignClient.class); // ... for (String basePackage : basePackages) { // ... Map<String, Object> attributes = annotationMetadata .getAnnotationAttributes( FeignClient.class.getCanonicalName()); // ... // 注册 FeignClient 为 BeanDefinition registerFeignClient(registry, annotationMetadata, attributes); } } } 将 FeignClient 包裹成 FeignClientFactoryBean private void registerFeignClient(BeanDefinitionRegistry registry, AnnotationMetadata annotationMetadata, Map<String, Object> attributes) { String className = annotationMetadata.getClassName(); // 将 FeignClient 包裹成 FeignClientFactoryBean BeanDefinitionBuilder definition = BeanDefinitionBuilder .genericBeanDefinition(FeignClientFactoryBean.class); // ... 一堆definition.addPropertyValue() definition.addPropertyValue("fallbackFactory", attributes.get("fallbackFactory")); definition.setAutowireMode(AbstractBeanDefinition.AUTOWIRE_BY_TYPE); // ... // 注册 FeignClientFactoryBean BeanDefinitionHolder holder = new BeanDefinitionHolder(beanDefinition, className, new String[] { alias }); BeanDefinitionReaderUtils.registerBeanDefinition(holder, registry); } FeignClientFactoryBean#getObject(),生成FeignClient 的代理对象 public Object getObject() throws Exception { return getTarget(); } /** * 根据指定的数据和上下文信息,生成一个 FeignClient 的代理对象 Client */ <T> T getTarget() { FeignContext context = applicationContext.getBean(FeignContext.class); // ... Client client = getOptional(context, Client.class); // ... Targeter targeter = get(context, Targeter.class); return (T) targeter.target(this, builder, context, new HardCodedTarget<>(type, name, url)); } // 最终会调用生成一个 FeignInvocationHandler 的代理对象 public <T> T target(Target<T> target) { return build().newInstance(target); } 4.生成FeignClient 的动态代理 FeignInvocationHandler public <T> T newInstance(Target<T> target) { // 解析请求为 MethodHandler Map<String, MethodHandler> nameToHandler = targetoHandlersByName.apply(target); Map<Method, MethodHandler> methodToHandler = new LinkedHashMap<Method, MethodHandler>(); List<DefaultMethodHandler> defaultMethodHandlers = new LinkedList<DefaultMethodHandler>(); // ... 代码省略 // 生成动态代理 InvocationHandler handler = factory.create(target, methodToHandler); T proxy = (T) Proxy.newProxyInstance(target.type().getClassLoader(), new Class<?>[] {target.type()}, handler); for (DefaultMethodHandler defaultMethodHandler : defaultMethodHandlers) { defaultMethodHandler.bindTo(proxy); } return proxy; } 5.FeignInvocationHandler 执行 invoke ,一步步调用,最终会调用 Client 的 execute()方法,执行远程调用 总结: 被@FeignClient 标记的 Interface 会在开启了@EnableFeignClients 之后,被 Spring 扫描到容器中,并且生成一个 FeignInvocationHandler 的动态代理 既然 FeignClient 会被生成一个动态代理,那么要执行到 findOrderByUserId() 方法,一定是通过FeignInvocationHandler 的 invoke() 方法被执行的,接着往下看 FeignClient 调用 先看一张图 由于没找到这张图的真正出处,引用该图暂未标明引用链接,如若该图作者发现可以联系本人,标明引用出处 上面我们已经分析完了FeignClient 是如何创建动态代理的,在我们按着FeignInvocationHandler 的 invoke() 方法往下分析之前,先看下上图中步骤 2,这一步就是 @RequestMapping如何在 Feign 中生效的 回头看下生成动态代理过程中有段代码 // 解析请求为 MethodHandler Map<String, MethodHandler> nameToHandler = target``oHandlersByName.apply(target); 这里完成了 Contract 对 SpringMVC 的解析 public Map<String, MethodHandler> apply(Target key) { // 这就用contract完成了方法上的SpringMVC注解的转换 // FeignClient标注的Interface 的每一个方法都会被解析成MethodMetadata // 对各种SpringMVC的注解进行解析,将解析出来的header,method,path,body,form param,返回值等等,放入了MethodMetadata中 List<MethodMetadata> metadata = contract.parseAndValidatateMetadata(key.type()); Map<String, MethodHandler> result = new LinkedHashMap<String, MethodHandler>(); // 遍历方法元数据 for (MethodMetadata md : metadata) { BuildTemplateByResolvingArgs buildTemplate; if (!md.formParams().isEmpty() && md.template().bodyTemplate() == null) { buildTemplate = new BuildFormEncodedTemplateFromArgs(md, encoder); } else if (md.bodyIndex() != null) { buildTemplate = new BuildEncodedTemplateFromArgs(md, encoder); } else { buildTemplate = new BuildTemplateByResolvingArgs(md); } // 在这里就创建了SynchronousMethodHandler,key就是方法名 // SynchronousMethodHandler就是所有的方法被代理后实际处理的处理器 result.put(md.configKey(), factory.create(key, md, buildTemplate, options, decoder, errorDecoder)); } return result; } 所以我们可以看到,Feign 之所以能用 SpringMVC 注解是因为专门对这层注解做了解析。 FeignInvocationHandler#invoke() FeignInvocationHandler#invoke() --> executeAndDecode(template, options) Object executeAndDecode(RequestTemplate template, Options options) throws Throwable { // 处理所有Interceptor: RequestInterceptor Request request = targetRequest(template); // ... Response response; try { // 执行Client#execute() response = client.execute(request, options); // ... } } LoadBalancerFeignClient#execute() public Response execute(Request request, Request.Options options) throws IOException { try { // ... 封装 request 成 ribbonRequest FeignLoadBalancer.RibbonRequest ribbonRequest = new FeignLoadBalancer.RibbonRequest( this.delegate, request, uriWithoutHost); // 配置 Client IClientConfig requestConfig = getClientConfig(options, clientName); return lbClient(clientName) .executeWithLoadBalancer(ribbonRequest, requestConfig).toResponse(); } lbClient(clientName) 整合 Ribbon 实例化出 FeignLoadBalancer lbClient(String clientName) --> this.lbClientFactory.create(clientName) public FeignLoadBalancer create(String clientName) { // FeignLoadBalancer 是 Feign 提供的 FeignLoadBalancer client = this.cache.get(clientName); if (client != null) { return client; } // IClientConfig ILoadBalancer 是 Ribbon 提供的 IClientConfig config = this.factory.getClientConfig(clientName); ILoadBalancer lb = this.factory.getLoadBalancer(clientName); ServerIntrospector serverIntrospector = this.factory.getInstance(clientName, ServerIntrospector.class); client = this.loadBalancedRetryFactory != null ? new RetryableFeignLoadBalancer(lb, config, serverIntrospector, this.loadBalancedRetryFactory) : new FeignLoadBalancer(lb, config, serverIntrospector); this.cache.put(clientName, client); // 该 client 本身封装了 Ribbon 的IClientConfig ILoadBalancer,在后面进行替换 url 和负载均衡发挥作用 return client; } FeignLoadBalancer如何负载均衡选择 Server public T executeWithLoadBalancer(final S request, final IClientConfig requestConfig) throws ClientException { LoadBalancerCommand<T> command = buildLoadBalancerCommand(request, requestConfig); try { // 这提交了一个匿名内部类进去,那么ServerOperation.call方法就一定会在submit方法里被调用 return command.submit( new ServerOperation<T>() { @Override public Observable<T> call(Server server) { URI finalUri = reconstructURIWithServer(server, request.getUri()); S requestForServer = (S) request.replaceUri(finalUri); try { return Observable.just(AbstractLoadBalancerAwareClient.this.execute(requestForServer, requestConfig)); } catch (Exception e) { return Observable.error(e); } } }) .toBlocking() .single(); 在 submit() 中调用selectServer(),进行 url 替换,选择一个服务实例 // LoadBalancerCommand.java public Observable<T> submit(final ServerOperation<T> operation) { final ExecutionInfoContext context = new ExecutionInfoContext(); if (listenerInvoker != null) { try { listenerInvoker.onExecutionStart(); } catch (AbortExecutionException e) { return Observable.error(e); } } // ribbon的重试参数 final int maxRetrysSame = retryHandler.getMaxRetriesOnSameServer(); final int maxRetrysNext = retryHandler.getMaxRetriesOnNextServer(); // Use the load balancer // selectServer 负载均衡选择实例 Observable<T> o = (server == null ? selectServer() : Observable.just(server)) ......省略部分代码 // 选择出服务实例后,对operation进行回调,进行url的替换,然后发起真正的http请求 return operation.call(server)... ......省略部分代码 // 选择一个服务实例 private Observable<Server> selectServer() { return Observable.create(new OnSubscribe<Server>() { @Override public void call(Subscriber<? super Server> next) { try { // 读取host信息,也就是服务名,然后调用负载均衡器chooseServer方法选择一个服务实例 Server server = loadBalancerContext.getServerFromLoadBalancer(loadBalancerURI, loadBalancerKey); next.onNext(server); next.onCompleted(); } catch (Exception e) { next.onError(e); } } }); } 构造了一个LoadBalancerCommand 构造了一个ServerOperation,包含了发起http调用的逻辑,作为参数传入- - LoadBalancerCommand.submit方法,后面会进行回调 在submit方法中,会调用selectServer方法,选择服务实例 selectServer方法调用loadBalancerContext.getServerFromLoadBalancer,最终调用负载均衡器chooseServer方法选择一个服务实例, 拿到服务实例后,将Server对象传入ServerOperation的call方法进行回调 ServerOperation用server的信息替换host里的服务名,拿到真正的请求地址 再调用子类也就是FeignLoadBalancer.execute方法执行http请求 默认的connectTimeout和readTimeout都是1000毫秒 响应结果封装为RibbonResponse 执行 http 请求 获取到了远程服务的真实地址,就可以采用 Http 方式调用了,问题是可提供Http 调用的方式有那么多(OkHttp 、ApacheHttpClient、RestTemplate 等等),Feign 怎么知道用哪个呢? 答案在 FeignAutoConfiguration 里 @Configuration(proxyBeanMethods = false) @ConditionalOnClass(ApacheHttpClient.class) @ConditionalOnMissingClass("com.netflix.loadbalancer.ILoadBalancer") @ConditionalOnMissingBean(CloseableHttpClient.class) @ConditionalOnProperty(value = "feign.httpclient.enabled", matchIfMissing = true) protected static class HttpClientFeignConfiguration { // ... } @Configuration(proxyBeanMethods = false) @ConditionalOnClass(OkHttpClient.class) @ConditionalOnMissingClass("com.netflix.loadbalancer.ILoadBalancer") @ConditionalOnMissingBean(okhttp3.OkHttpClient.class) @ConditionalOnProperty("feign.okhttp.enabled") protected static class OkHttpFeignConfiguration { // ... } 通过 @ConditionalOnClass 、@ConditionalOnProperty 等条件注解 来匹配用哪个 http 客户端,所以我们在使用过程中也是无感知的,只要我们引入 OkHttp 或者 ApacheHttpClient 相关的 Maven 依赖,就可以完成调用了 至此,FeignClient 被注册,被动态代理,被执行,整个流程已经清晰了,上面的问题也应该都有了答案,还有一个:Ribbon 是如何知道我们用到的是哪个注册中心,是 Eureka 是 Nacos ?他又是如何获取注册中心上的服务的? Ribbon 获取注册中心服务路由 既然我们在使用过程中没有自己指定,那么我猜想是不是 Ribbon 自己注册的时候自己会选择呢?我们就从Ribbon 的注册入手 RibbonClientConfiguration ,果然 配置ILoadBalancer 在 RibbonClientConfiguration 中会配置 ILoadBalancer,会返回一个 ZoneAwareLoadBalancer 实例 @Bean @ConditionalOnMissingBean public ILoadBalancer ribbonLoadBalancer(IClientConfig config, ServerList<Server> serverList, ServerListFilter<Server> serverListFilter, IRule rule, IPing ping, ServerListUpdater serverListUpdater) { if (this.propertiesFactory.isSet(ILoadBalancer.class, name)) { return this.propertiesFactory.get(ILoadBalancer.class, config, name); } return new ZoneAwareLoadBalancer<>(config, rule, ping, serverList, serverListFilter, serverListUpdater); } 更新注册中心列表 restOfInit() --> restOfInit() --> updateListOfServers --> servers = serverListImpl.getUpdatedListOfServers(); public void updateListOfServers() { List<T> servers = new ArrayList<T>(); if (serverListImpl != null) { // 更新注册中心服务列表 servers = serverListImpl.getUpdatedListOfServers(); LOGGER.debug("List of Servers for {} obtained from Discovery client: {}", getIdentifier(), servers); if (filter != null) { servers = filter.getFilteredListOfServers(servers); LOGGER.debug("Filtered List of Servers for {} obtained from Discovery client: {}", getIdentifier(), servers); } } updateAllServerList(servers); } ServerList<T> serverListImpl 获取服务列表是通过 serverListImpl 来获取的,serverListImpl 是一个interface,不同的注册中心服务商会实现 ServerLis, 比如 Nacos 的实现NacosServerList 。 这样我们就不用指定,Ribbon 就自己知道是从哪个注册中心获取了。

优秀的个人博客,低调大师

PostgreSQL从库只读的实现原理

我们接触到的数据库,基本都提供了只读实例的功能。在业务允许的情况下可以将一些读取数据的请求下发至只读实例,减缓primary的压力,以获得更佳的性能。 物理从库只读已经是一个常识问题,在PostgreSQL中具体是怎么实现的呢,一起来看看 一、报错分析 从报错入手分析,在只读库里执行写操作,报错如下: postgres=# select * into tbl_t from tbl_test; ERROR: cannot execute SELECT INTO in a read-only transaction postgres=# 报错的函数为: /* * PreventCommandIfReadOnly: throw error if XactReadOnly * * This is useful partly to ensure consistency of the error message wording; * some callers have checked XactReadOnly for themselves. */ void PreventCommandIfReadOnly(const char *cmdname) { if (XactReadOnly) ereport(ERROR, (errcode(ERRCODE_READ_ONLY_SQL_TRANSACTION), /* translator: %s is name of a SQL command, eg CREATE */ errmsg('cannot execute %s in a read-only transaction', cmdname))); } 当XactReadOnly为true时,就抛出报错,XactReadOnly是一个Bool类型的全局变量。那这里大概明白设计思路了,当执行一些操作时调用PreventCommandIfReadOnly函数,如果库是只读状态进行写操作就抛出报错。 报错堆栈: (gdb) bt #0 PreventCommandIfReadOnly (cmdname=0xbab6f8 'SELECT INTO') at utility.c:409 #1 0x00000000008c24a5 in standard_ProcessUtility (pstmt=0x1faef00, queryString=0x1fae098 'select * into tbl_t from tbl_test;', context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x1fafa18, qc=0x7ffc8ac8a180) at utility.c:566 #2 0x00000000008c23cc in ProcessUtility (pstmt=0x1faef00, queryString=0x1fae098 'select * into tbl_t from tbl_test;', context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x1fafa18, qc=0x7ffc8ac8a180) at utility.c:524 #3 0x00000000008c14e2 in PortalRunUtility (portal=0x1fffa58, pstmt=0x1faef00, isTopLevel=true, setHoldSnapshot=false, dest=0x1fafa18, qc=0x7ffc8ac8a180) at pquery.c:1157 #4 0x00000000008c16ce in PortalRunMulti (portal=0x1fffa58, isTopLevel=true, setHoldSnapshot=false, dest=0x1fafa18, altdest=0x1fafa18, qc=0x7ffc8ac8a180) at pquery.c:1303 #5 0x00000000008c0c6c in PortalRun (portal=0x1fffa58, count=9223372036854775807, isTopLevel=true, run_once=true, dest=0x1fafa18, altdest=0x1fafa18, qc=0x7ffc8ac8a180) at pquery.c:779 #6 0x00000000008bb204 in exec_simple_query (query_string=0x1fae098 'select * into tbl_t from tbl_test;') at postgres.c:1239 #7 0x00000000008bf053 in PostgresMain (argc=1, argv=0x1fd7af0, dbname=0x1fd7a28 'postgres', username=0x1fd7a08 'postgres') at postgres.c:4315 #8 0x0000000000820e1f in BackendRun (port=0x1fd13f0) at postmaster.c:4536 #9 0x0000000000820630 in BackendStartup (port=0x1fd13f0) at postmaster.c:4220 #10 0x000000000081cf62 in ServerLoop () at postmaster.c:1739 #11 0x000000000081c843 in PostmasterMain (argc=3, argv=0x1fa9d70) at postmaster.c:1412 #12 0x0000000000733286 in main (argc=3, argv=0x1fa9d70) at main.c:210 (gdb) p XactReadOnly $1 = true 接下来追踪全局变量XactReadOnly 在什么时候被赋值为true。 二、变量追踪 走读代码:postmaster守护进程fork出postgres后,在InitPostgres阶段StartTransaction()函数根据是否RecoveryInProgress来赋值,如果RecoveryInProgress()为true就设置XactReadOnly = true /* * Make sure we've reset xact state variables * * If recovery is still in progress, mark this transaction as read-only. * We have lower level defences in XLogInsert and elsewhere to stop us * from modifying data during recovery, but this gives the normal * indication to the user that the transaction is read-only. */ if (RecoveryInProgress()) { s->startedInRecovery = true; XactReadOnly = true; } 使用gdb attach postmasterPID 后,抓到了这个过程 Breakpoint 3, StartTransaction () at xact.c:1895 1895 s = &TopTransactionStateData; (gdb) bt #0 StartTransaction () at xact.c:1895 #1 0x0000000000536318 in StartTransactionCommand () at xact.c:2827 #2 0x0000000000a40778 in InitPostgres (in_dbname=0x1fd7a28 'postgres', dboid=0, username=0x1fd7a08 'postgres', useroid=0, out_dbname=0x0, overrid e_allow_connections=false) at postinit.c:739 #3 0x00000000008beb60 in PostgresMain (argc=1, argv=0x1fd7af0, dbname=0x1fd7a28 'postgres', username=0x1fd7a08 'postgres') at postgres.c:3933 #4 0x0000000000820e1f in BackendRun (port=0x1fd13f0) at postmaster.c:4536 #5 0x0000000000820630 in BackendStartup (port=0x1fd13f0) at postmaster.c:4220 #6 0x000000000081cf62 in ServerLoop () at postmaster.c:1739 #7 0x000000000081c843 in PostmasterMain (argc=3, argv=0x1fa9d70) at postmaster.c:1412 #8 0x0000000000733286 in main (argc=3, argv=0x1fa9d70) at main.c:210 (gdb) p XactReadOnly $1 = false (gdb) list 1890 VirtualTransactionId vxid; 1891 1892 /* 1893 * Let's just make sure the state stack is empty 1894 */ 1895 s = &TopTransactionStateData; 1896 CurrentTransactionState = s; 1897 1898 Assert(!FullTransactionIdIsValid(XactTopFullTransactionId)); 1899 (gdb) n 1896 CurrentTransactionState = s; (gdb) 1909 s->state = TRANS_START; (gdb) 1910 s->fullTransactionId = InvalidFullTransactionId; /* until assigned */ (gdb) n 1913 xact_is_sampled = log_xact_sample_rate != 0 && (gdb) 1922 s->nestingLevel = 1; (gdb) 1923 s->gucNestLevel = 1; (gdb) 1924 s->childXids = NULL; (gdb) 1925 s->nChildXids = 0; (gdb) 1926 s->maxChildXids = 0; (gdb) 1932 GetUserIdAndSecContext(&s->prevUser, &s->prevSecContext); (gdb) 1945 if (RecoveryInProgress()) (gdb) 1947 s->startedInRecovery = true; (gdb) p RecoveryInProgress() $2 = true (gdb) n 1948 XactReadOnly = true; (gdb) p XactReadOnly $3 = true XactReadOnly赋值是在StartTransaction ()函数中完成的,首次赋值是在InitPostgres环节,除此之外,后续每次启动事务后会重新赋值。 XactReadOnly是否为ture取决于RecoveryInProgress()的返回值是否为true。对于Primary实例 startup进程不是常驻内存的,因此只有在启动过程中以及crash后进行recovery,完成后startup进程退出;对于standby 实例来说startup进程是常驻内存的,一直通过redo来回放primary发送的日志,因此RecoveryInProgress()一直为ture。 RecoveryInProgress()函数逻辑很简单,返回值取决于共享内存xlogctl->SharedRecoveryState的值,只有在StartupXlog函数退出时会修改为RECOVERY_STATE_DONE;因此在standby实例中RecoveryInProgress()函数一直返回true /* * Is the system still in recovery * * Unlike testing InRecovery, this works in any process that's connected to * shared memory. * * As a side-effect, we initialize the local TimeLineID and RedoRecPtr * variables the first time we see that recovery is finished. */ bool RecoveryInProgress(void) { /* * We check shared state each time only until we leave recovery mode. We * can't re-enter recovery, so there's no need to keep checking after the * shared variable has once been seen false. */ if (!LocalRecoveryInProgress) return false; else { /* * use volatile pointer to make sure we make a fresh read of the * shared variable. */ volatile XLogCtlData *xlogctl = XLogCtl; LocalRecoveryInProgress = (xlogctl->SharedRecoveryState != RECOVERY_STATE_DONE); /* * Initialize TimeLineID and RedoRecPtr when we discover that recovery * is finished. InitPostgres() relies upon this behaviour to ensure * that InitXLOGAccess() is called at backend startup. (If you change * this, see also LocalSetXLogInsertAllowed.) */ if (!LocalRecoveryInProgress) { /* * If we just exited recovery, make sure we read TimeLineID and * RedoRecPtr after SharedRecoveryState (for machines with weak * memory ordering). */ pg_memory_barrier(); InitXLOGAccess(); } /* * Note: We don't need a memory barrier when we're still in recovery. * We might exit recovery immediately after return, so the caller * can't rely on 'true' meaning that we're still in recovery anyway. */ return LocalRecoveryInProgress; } } 三、小结 通过前边的分析,将设定只读,以及只读处理的过程通过框图来表示。 1、 左边灰色框表示只读的设定,在fork出postgres之后,根据是否RecoveryInProgress来设定是否只读,实例为standby角色则设置为只读; 2、 右边框图表示只读处理的过程,执行器进行判断,如果实例为standby角色,并且执行写操作,则调用PreventCommandIfReadOnly函数抛出报错终止写操作 整体来看pg通过一个bool全局变量XactReadOnly,设定相关的逻辑,来操作实例是否只读,以及只读处理。 四、延伸 1、XactReadOnly变量对应guc参数transaction_read_only,可以使用show命令查看;但是这个参数是GUC_NO_RESET_ALL类,也就是说不能通过alter system方式修改; 2、如何设置primary实例为只读状态? Alter system set default_transaction_read_only to on; select pg_reload_conf(); 即可 { {'default_transaction_read_only', PGC_USERSET, CLIENT_CONN_STATEMENT, gettext_noop('Sets the default read-only status of new transactions.'), NULL }, &DefaultXactReadOnly, false, NULL, NULL, NULL }, { {'transaction_read_only', PGC_USERSET, CLIENT_CONN_STATEMENT, gettext_noop('Sets the current transaction's read-only status.'), NULL, GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE }, &XactReadOnly, false, check_transaction_read_only, NULL, NULL },

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册