项目实施请求分发流水记

欢迎访问我的个人博客:kevoo.org

 


接到这样的需求:把a1系统中的报表中心里的全部报表放到单独的服务器上去运行,其它功能还在以前的服务器。
分析解决:
报表中心里的全部报表都走xxxx/report/xxxx的url,经过讨论,认为可以通过nginx的location元素,实现不同url的请求分发,达到报表与其它业务逻辑分开处理的目的。
所以就兴冲冲的在新服务器部署了a1,然后在nginx服务器上把所有xxx/report/xxx的请求转到新的服务器上了。
可是一测试,问题来了,登录后,点击所有报表,都会跳转到登录页面。问题很明显--用户登录信息丢失了。(因为在页面里,会从session取当前用户信息,如果取不到,会自动跳转到登录页面,让用户登录)


仔细一想,当然会丢失:两个服务器是两个tomcat, session都不一样,登录A服务器后生成的session,肯定是保存在A服务器的内存里的, 执行报表查询时,却要从B服务器取该session,怎么能取到?


看来解决方案也简单了,让两个tomcat实现session共享呗:
从网上下载tomcat共享插件,共5个jar包(javolution-5.4.3.1.jar,memcached-2.4.2.jar,memcached-session-manager-1.3.0.jar,msm-javolution-serializer-cglib-1.3.0.jar,msm-javolution-serializer-jodatime-1.3.0.jar),全部放到tomcat根目录下的lib目录里,然后修改conf/context.xml,在<Context>元素里增加以下内容:
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
                memcachedNodes="n1:111.111.111.11:11211"
                requestUriIgnorePattern=".*\.(png|gif|jpg|css|js)$"
                sessionBackupAsync="false"
                sessionBackupTimeout="100"
                transcoderFactoryClass="de.javakaffee.web.msm.serializer.javolution.JavolutionTranscoderFactory"
                copyCollectionsForSerialization="false"
        />
之后,重启tomcat,在A与B服务器的tomcat里都做相同的配置即可。


通过telnetmemcache服务器,发现拿着相同的jsessionid可以取到值了,说明配置成功。


再次测试,发现还是之前的问题,所有xxx/report/xxx的链接都会跳转到登录页面。
既然session共享已经实现,为什么还是取不到用户信息?  
仔细想想,应该是从两台tomcat里取session信息时,取得key不一样,就是说登录vms后,用户缓存登录信息的key是key1(假设),但跳转到报表页面时,取用户信息用的key不是key1,而是keyother,只有存时用key1,取时用keyother,才会出现取不到值的现象。


于是查看nginx服务器的conf文件,发现在location里的设置里,没有对cookie做专门的设置,就是说,在做请求转发时,没有把cookie信息设置进header头里。于是重新修改了location的配置:


location /a1/report{
                        proxy_pass http://111.111.111.111:9080;
                        proxy_set_header Host $host;
proxy_set_header Cookie $http_cookie;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                }


这样,问题基本得到解决。


运行半天,又出现另一个问题,tomcat下的一个项目,即a2,登录信息依然无效,并且这个项目,还是跑在唯一的一台服务器上,为什么还是取不到session信息呢?
经过代码分析,所有放入memcache里的对像都要实现serializables接口,由于a2放的是user对象,但User类没有实现该接口,所以存入失败导致的。在修改代码,让User类型实现该接口后,问题得到解决。
 

 

 

### 使用Swoole实现服务架构下的支付平台项目 #### 1. 架构概述 在微服务架构中,支付平台作为核心模块之一,通常需要具备高可用性和高性能。采用Swoole框架可以有效提升系统的响应速度和服务稳定性。由于Swoole内置了协程网络服务器并支持常驻内存运行[^2],这使得其非常适合处理大量并发请求。 #### 2. 技术选型与环境搭建 为了构建一个基于Swoole的微服务平台,建议选用如下技术栈: - **编程语言**: PHP (借助于Swoole扩展) - **数据库连接池**: 可以考虑使用 `EasySwoole` 提供的相关组件来管理MySQL或其他类型的持久化存储链接 - **消息队列**: RabbitMQ, Kafka 等用于异步通信和任务分发 - **缓存机制**: Redis 来加速数据读取效率以及减轻DB压力 对于开发环境而言,则需先安装好必要的软件包如PHP7.x及以上版本,并通过PECL命令安装最新版的Swoole扩展库[^3]. ```bash pecl install swoole echo "extension=swoole.so" >> /etc/php.d/swoole.ini ``` #### 3. 应用层设计 应用层面的设计应当遵循RESTful API原则,定义清晰的服务接口文档;同时考虑到安全性因素,在传输敏感信息时应启用HTTPS协议加密通道。另外还需要特别注意以下几点: - 实现统一的身份验证机制(OAuth2) - 对外暴露的安全API端点应该受到严格的访问控制策略保护 - 敏感操作日志录功能不可缺失以便后续审计追踪 #### 4. 关键特性集成 针对支付业务场景的特点,以下是几个重要的特性的具体实施方案: ##### 支付网关(Payment Gateway) 利用Swoole提供的HTTP Client类轻松发起对外部第三方支付渠道(支付宝、微信等) 的调用请求,并封装成易于使用的SDK形式提供给其他内部子系统调用. ##### 幂等性(Idempotency) 为了避免重复提交订单造成资金损失的风险,可以在每次交易前生成唯一标识符(UUID),并将该ID连同其它必要参数一起发送至下游服务进行校验确认是否存在相同流水号的历史录. ##### 异步通知(Callback Notification) 当一笔转账完成后,由接收方主动回调上游商户告知状态变更情况。此时可借助Swoole内建的消息推送能力完成即时反馈流程而无需轮询查询结果[^4]. #### 5. 性能优化措施 尽管Swoole本身已经提供了不错的性能表现,但在实际生产环境中仍然可以通过一些手段进一步提高整体吞吐量: - 合理配置worker进程数量以充分利用多核CPU资源 - 尽可能减少不必要的I/O阻塞等待时间 - 利用Redis集群代替单机实例增强KV存储环节的数据可靠性和读写速率 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值