头像服务端设计思路

思路

一 把图片上传到服务端、命名以用户的（用户名md5）作为文件名。要是以前有文件，覆盖以前的文件

二编写一个servlet处理获取头像请求。

servlet接收一个用户名md5+大小的参数

根据 用户名md5+大小生成对应的图片

例如

用户名为ada

上传到服务端的位置为

/gravatar/ada.jpg

请求地址：/webstore/headimg/ada.jpg?s=120

对应的服务端文件地址

/gravatar/ada.jpg(原图片)

/gravatar/ada/120.jpg (缩放过的图片)

请求地址：/webstore/headimg/ada.jpg?s=200

对应的服务端文件地址

/gravatar/ada.jpg(原图片)

/gravatar/ada200.jpg (缩放过的图片)

简单实现：

https://git.oschina.net/cng1985/webstore.git

时间： 2024-12-28 16:09:21

头像服务端设计思路的相关文章

TYPESDK手游聚合SDK服务端设计思路与架构之一：应用场景分析

TYPESDK 服务端设计思路与架构之一:应用场景分析 作为一个渠道SDK统一接入框架,TYPESDK从一开始,所面对的需求场景就是多款游戏,通过一个统一的SDK服务端,能够同时接入几十个甚至几百个各种渠道的SDK.而且这些渠道接口的具体接入字段和接入逻辑,每个月以至每周,都可能发生或大或小的变动.在这样一个复杂的应用场景下,我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢? 首先我们需要厘清,在整个应用场景中,TYPESDK所处的位置,以及它所需要实现的核心功能. 图1 如图1所示,T

TYPESDK 服务端设计思路与架构之六：性能及调优初步

经过本系列前几篇文字的分析和设计,我们成功地开发出了自己的SDK服务端.在我们自己的调试环境下运行一切正常,但是当然我们不能就这样把这套SDK服务端部署上线到正式生产环境,稍有正式大型项目经验的同学应该都知道性能优化以及部署上线相关设计对于服务端项目的重要性.我们到目前为止的分析设计中,并没有考虑到这些设计.那么,针对我们SDK服务端这样的应用场景,应该着重关注哪些相关的优化和设计呢? 数据存取优化 在我们的应用场景中,需要使用到存储的场景主要在以下几个处理中: l  获取配置信息 对每个收到的

TYPESDK手游聚合SDK服务端设计思路与架构之三：流程优化之订单保存与通知

经过前两篇文字的分析与设计,我们已经可以搭建出一个能够支持多游戏多渠道的聚合SDK服务端,但这只是理想化状态下的一个简化模型.如果接入渠道的逻辑都是按照理想化的简化过程来构建,那么对于支付的请求,我们可以简化成这样几步: 游戏客户端创建订单. 游戏客户端(通过TYPESDK客户端)调用渠道lib库中相应接口,发起支付. 用户在弹出的支付窗口完成支付. TYPESDK服务端等待渠道服务端的回调,收到回调后通知游戏服务端. 游戏服务端执行发货动作. 但是显然这个简化流程在实际上线时是不够满足需求的,

rsync服务端排错思路

rsync服务端排错思路 查看rsync服务配置文件路径是否正确,正确的默认路径为/etc/rsyncd.conf 查看配置文件里host allow,host deny,允许的ip网段是否是允许客户端访问的ip网段 查看配置文件中path参数里的路径是否存在,权限是否正确(正常应为配置文件中的UID参数对应的属主和组) 查看rsync服务是否启动,查看命令为:ps -ef|grep rsync.端口是否存在netstat -lnt|grep 873 查看iptables防火墙和selinux是

angular1常用组件和服务的设计思路

每个Angular“应用程序”ng-app都有一个 injector ,负责创建并查找依赖,当缓存中没有依赖key1时,记依赖对象为{key1:null,key2:value2,...},后来当key1出现时,key1修改依赖对象为{key1:value1,key2:value2,...},所有文件加载完毕以后,执行全局配置函数config和run,如果所有文件加载完毕,key1也没有出现,则会报错,不会执行全局配置函数.一.标题组件的设计思路:1.标签内属性传参(1)标题内容2.模板(1)<i

Apollo服务端设计原理剖析

本文摘自于<Spring Cloud微服务 入门 实战与进阶>一书. 1 配置发布后的实时推送设计 配置中心最重要的一个特性就是实时推送了,正因为有这个特性,我们可以依赖配置中心做很多事情.在我自己开发的Smconf这个配置中心,Smconf是依赖于Zookeeper的Watch机制来实现实时推送. 上图简要描述了配置发布的大致过程: 用户在Portal中进行配置的编辑和发布 Portal会调用Admin Service提供的接口进行发布操作 Admin Service收到请求后,发送Rele

《攻城Online》快速原型：服务端设计

“攻城”服务端采用Photon引擎的框架,其主要逻辑如以下UML所示. 服务端的启动入口为ServerApplication,该类包含着相关的Collection数据集合,而Collection内又有与数据库文件夹Database关联的文件.两个文件夹的内容如图. 简单来说,ServerApplication内缓存着各类数据,并完成与数据库等的关联.而本篇的重点是ServerPeer这个类.下面介绍什么是Peer. 每当一个客户端连接到服务端时,服务端会自动生成一个客户端连接实例,称其为Peer

WebService或HTTP服务端接收请求转发消息到另一个服务端-实现思路

1.需求结构(WebService) A客户端<->B服务端<->C服务端 说明: a.在B服务端上面添加配置项(1.是否转发消息到C服务端:2.C服务端IP和端口): b.A客户端发消息到B服务端,B服务端收到消息判断是否需要转发,如果是需要转发就将消息转发给C服务端,然后消息再依次返回. 2.现在就是B服务端如何接受A客户端消息并直接转发给C服务端? 目前我找到就一下方案: a.apache camel:基于规则路由和中介引擎,貌似很强大时间紧,木有时间研究.... b.土办法

Android Socket 聊天工具（一个服务端实现多个客户端间通信）

如果某位朋友也打算做这个Socket聊天工具,本人有个小小的建议,你可以不必太着急些代码,先想清楚自己最终要做到怎样效果,然后把自己的思路都写下来,有一个基本的实现方法.在写代码时就按照自己的思路一步一步地写下去,这样可以很好地避免写代码时由于思路不清左删右改. 以下是本人程序的设计思路 客户端设计思路: 一 用户登录界面 1 用一个EditText作为用户名输入口,用一个按键确定. 2 注册一个广播接收器,专门接收由后来的聊天界面发过来的消息广播(包括发信人,收信人,消息体). 3 创建一个客