信息比较长，如果你感兴趣那就耐心看岗位要求把，期待你的简历

招聘部门及岗位：

技术部：
JAVA开发工程师、测试工程师、C/C++开发工程师、数据开发工程师（ETL开发）、Linux系统工程师、
Linux研发工程师、运维开发工程师、开发DBA、WEB安全工程师、系统安全工程师、系统管理工程师、
大规模集群应用管理工程师、技术支持工程师、工具开发工程师、内网开发工程师、大规模网站监控工程师、
数据挖掘工程师、前端开发工程师

无线支付：无线产品经理、手机开发工程师（C++）、J2EE开发工程师、测试工程师
商户事业部：培训专员、数据分析师—数据挖掘方向、技术支持、商户支持专员
用户事业部：运营专员

下面是具体的岗位要求：

技术部：

JAVA开发工程师
工作地点：杭州/上海
招聘人数：267人
职位描述:
1.进行软件详细设计和编码实现；满足功能；确保性能.质量和安全；
2.维护和升级现有软件产品；快速定位并修复现有软件缺陷。
任职要求：
1.专业不限；计算机.软件工程.数学等相关专业优先考虑；
2.掌握Web编程；有使用Java语言进行Web开发的经验；了解Spring 等开源框架优先；
3.熟悉Linux/Unix开发环境.常用设计模式.基于数据库的设计和开发；
4.有系统分析和设计的项目经验者优先考虑；
5.有良好的软件工程知识和质量意识；
6.良好的学习沟通能力；团队合作意识及抗压能力。

测试工程师
工作地点：杭州
招聘人数:68人
职位描述：
1.进行业务需求分析和系统设计分析；设计测试计划和测试方案；
2.根据用例对系统进行测试；发现；报告和跟踪缺陷；
3.应用自动化测试方式设计和编写自动化测试脚本或自主开发测试工具；
任职要求：
1.计算机.软件工程相关专业大学本科学历及以上；
2.具备良好的程序编写基础思想与技能；有C或C++或C#或Java的实际应用经验；有B/S系统编程经验优先；
3.熟悉SQL基本语法；了解SQL Server或Oracle数据库的基本应用及数据库设计基础；
4.熟悉软件工程与软件测试基本流程与理念；有志于从事软件测试工作。有软件测试工作实践经验者优先；
5.良好的团队合作精神；良好的沟通技巧；解决问题及抗压能力强。

C/C++开发工程师
工作地点：杭州
招聘人数：5人
职位描述：
1．进行软件详细设计和编码实现；满足功能；确保性能.质量和安全；
2．维护和升级现有软件产品；快速定位并修复现有软件缺陷。
任职要求：
1．本科及以上学历；计算机相关专业；
2.熟练掌握C/C++语言.数据结构及算法；
3.熟悉Linux的常用命令.操作和脚本语言；
5.具有优秀的分析.解决实际问题的能力；
6.良好的沟通能力.有责任心和团队合作意识。

数据开发工程师（ETL开发）
工作地点：杭州
招聘人数：6人
职位描述：
1．支付宝数据仓库部门主要职责是决策支持；通过收集.分析.挖掘公司内所有数据(包含日志.数据库.文件.外部信息等)；
2．为高层提供决策.战略数据支持；我们在数据库技术.分布式计算.数据挖掘.算法研究等方面拥有业内领先的实力。
任职要求：
1．本科及以上学历；计算机及相关专业毕业；
2．具有很强的逻辑思维和推理能力；
3．优秀的沟通和学习能力 ；有算法和数据挖掘背景者优先；
4．熟悉SQL SERVER/ORACLE/DB2/MY SQL/ GREENPLUM等数据库中一种；有SQL开发经验者优先；
5．对海量数据计算技术有强烈的兴趣；喜欢创新；挑战难题；有分布式计算平台（Hadoop,Hive更佳）经验者优先。

Linux系统工程师
工作地点：北京/杭州
招聘人数： 10人
职位描述：
1．负责Linux内核等基础系统服务组件实现算法和源码的研究分析；
2．针对支付宝的业务需求优化算法代码；增加新功能；使应用取得更佳的资源利用率；
任职要求：
1．熟悉Linux平台下的C/C++语言编程；对数据结构和算法设计有较深刻的理解；
2．熟悉Linux（类UNIX）内核；阅读过内核中的主要模块(文件系统；TCP/IP, I/O；内存管理)源代码者优先；
3．熟悉各种计算机体系结构(包括X86_64,MIPS等）；
4．具备很强的分析和解决问题的能力；对于攻关疑难问题具有强烈的兴趣；
5．对技术敏感而细致；乐于发现；分析和解决复杂问题；
6．善于学习新的知识；具有开拓创新精神；
7．很强的责任心；勤于动手；不怕繁琐；重视流程规范。

Linux研发工程师
工作地点：北京/杭州
招聘人数：5人
职位描述：
1．负责各类基础服务平台研究.开发和优化；
2．支付宝网站运行容量优化和稳定性技术研究和开发；
3．针对业务需求；开发完善各业务基础平台；为各业务提供更好的底层平台支持。
任职要求：
1．计算机软件.数学等相关专业大学本科学历及以上；Linux社区成员优先；
2．对在线支付.Linux开源软件等有浓厚的兴趣和钻研能力；
3．具有出色的计算机算法和数据结构构建能力和实现能力；
4．对技术敏感而细致；乐于发现；分析和解决复杂问题；
5．具有良好的使命驱动感；具备良好的团队合作精神和沟通能力。

运维开发工程师
工作地点：杭州/上海
招聘人数：5人
职位描述：
1．设计.开发自动化管理工具或系统；提升系统容量性能和稳定性；
2．密切配合网站产品的设计.研发和部署；提升网站健壮性和运维性；
3．对分布式应用和网站的稳定性.可用性.健壮性负责；
4．研究制定运维策略.预案和相关解决方案；提升运维规范性。
任职要求：
1．对在线支付.Linux.WEB技术（Apache；MySQL；Tomcat）.脚本编程.JAVA开发等有浓厚的兴趣；
2．熟悉TCP/IP.HTTP等协议；掌握PHP.Perl.Shell.JAVA等语言的一种；有Linux/Unix维护或开发经验优先；
3．优秀的沟通能力；出色的学习与钻研能力；良好的问题分析与解决能力；
4．具有良好的自我驱动能力和执行能力；以及获得结果的能力。

开发DBA
工作地点：杭州/上海
招聘人数： 5人
职位描述：
1．参与开发项目建设；根据业务逻辑进行数据库方面设计和优化；
2．审核程序中SQL语句和逻辑；进行性能优化；
3．处理线上数据库的变更；确保项目发布；跟踪项目上线情况；发现并解问题；
4．管理开发；测试环境的数据库。
任职要求：
1．本科以上学历；对计算机技术有浓厚的兴趣；
2．对程序语言；数据结构或数据分析（数据统计）有较好的了解；
3．熟悉Oracle或MySQL数据库；有以上两种数据库学习或实践经历；
4．熟悉和灵活运用两种以上的脚本语言；包括但不限于：Shell.Perl；熟悉Java程序编写者优先；
5．具备很强的分析和解决问题的能力；对于攻关疑难问题具有强烈的兴趣；
6．具有良好的使命驱动感；具备良好的团队合作精神和沟通能力。

WEB安全工程师
工作地点：杭州/上海
招聘人数：5人
职位描述：
1．负责WEB应用的安全测试和安全管理；
2．参与应用系统安全开发流程；执行应用系统安全代码审核；
3．合作开发完成安全产品。
任职要求：
1．了解信息系统安全攻防技术；有安全工具开发经验.安全技术大赛经验者优先；
2．具有独立分析研究信息安全漏洞的能力；并制定完善的修补方案；
3．熟悉Windows或Linux/Unix操作系统结构；有内核开发经验者优先；
4．对TCP/IP协议和网络工程技术有深入了解；掌握网络编程技术；
5．精通主流UNIX平台系统管理和网络管理；精通Perl；Shell编程；
6．了解跨站脚本攻击.SQL注射等Web安全攻防原理；理解多种Web应用技术（Java.PHP.JSP）；并熟悉相关的安全问题；
7．有独立判断问题能力；有较强的分析问题及提出解决建议方案的能力；
8．具有良好的使命驱动感；具备良好的团队合作精神和沟通能力。

系统安全工程师
工作地点：杭州/上海
招聘人数：5人
职位描述：
1．参与系统网络的漏洞分析；以及漏洞修补方案的制定；
2．参与系统漏洞修补；应急响应信息系统安全事件；
3．规范系统网络安全运维。
任职要求：
1．了解信息系统安全攻防技术；有安全工具开发经验.安全技术大赛经验者优先；
2．具有独立分析研究信息安全漏洞的能力；并制定完善的修补方案；
3．熟悉Windows或Linux/Unix操作系统结构；有内核开发经验者优先；
4．对TCP/IP协议和网络工程技术有深入了解；掌握网络编程技术；
5．精通主流Unix平台系统管理和网络管理；精通Perl；Shell编程;
6．有独立判断问题能力；有较强的分析问题及提出解决建议方案的能力；
7．具有良好的使命驱动感；具备良好的团队合作精神和沟通能力。

系统管理工程师
工作地点：北京/杭州
招聘人数： 5人
职位描述：
1．负责Linux和Unix系统的运营.维护.优化等工作；
2．负责存储.基础服务等方面的技术支持工作；
3．负责安全或网络相关的辅助技术支持工作。
任职要求：
1．理工科专业大学本科学历及以上；Linux社区成员优先；
2．熟悉Linux.Unix等操作系统的管理.维护.开发和使用；
3．熟悉和灵活运用两种以上的脚本语言；包括但不限于：Shell.Perl等；
4．熟悉TCP/IP协议.了解常用的网络服务和WEB服务器配置；
5．了解WEB应用相关工具并拥有实际经验者优先；
6．具备良好的团队合作精神和沟通能力，拥有优秀的解决问题能力；
7．有较好专业基础者，可降低学历要求。

大规模集群应用管理工程师
工作地点：杭州/上海
招聘人数：10人
职位描述：
1．大规模互联网集群应用的部署规划.实施.维护和优化；
2．参与支付宝网站应用产品的设计和研发；提升系统性能和稳定性；
3．解决线上涉及网站应用.网络.操作系统及相关软件程序的各种问题；
4．研发和测试环境建设.维护和支持；解决测试环境的各种问题；提升测试环境效率。
任职要求：
1．对在线支付.Linux.WEB技术（Apache；MySQL；Tomcat）.脚本编程.JAVA开发等有浓厚的兴趣；
2．熟悉TCP/IP.HTTP等协议；掌握PHP.Perl.Shell.JAVA等语言的一种；熟悉Linux/Unix维护或开发者优先；
3．优秀的沟通能力；出色的学习与钻研能力；良好的问题分析与解决能力；
4．具有良好的自我驱动能力和执行能力；以及获得结果的能力。

技术支持工程师
工作地点：杭州/上海
招聘人数：5人
职位描述：
1．负责网站系统故障和问题的诊断.分析和解决；协调重大故障处理.分析；推进改善措施落实；
2．针对故障以及网站维护等重大事件进行业务影响分析；并进行影响预警或通告；
3．设计.开发技术支持流程和工具；提升技术支持服务水平和品质。
任职要求：
1．对互联网网站应用.计算机技术和解决问题具有浓厚的兴趣；
2．熟悉Java开发语言或脚本编程语言；了解Linux和TCP/IP网络技术；
3．具有良好的系统化思维.问题分析与解决能力；具有良好Troubleshooting技能；
4．优秀的沟通和协调能力；具有很好的客户服务意识；
5．具有良好的学习能力.自我驱动能力和执行能力，以及获得结果的能力。

工具开发工程师
工作地点：杭州
招聘人数：5人
职位描述：
1．负责研发.运维工具和流程平台的开发和维护；提高研发.运行工作效率；
2．负责公司部分工作工具和流程平台开发和支持；提高办公效率。
任职要求：
1．对研发流程和工具.运行服务流程和平台具有浓厚的兴趣；
2．对Java和PHP等开发语言具有优秀的钻研能力和应用能力；
3．熟悉Linux/Unix开发环境.常用设计模式.基于数据库的设计和开发；
4．具有良好的软件工程和质量意识和能力；
5．优秀的沟通和协调能力；具有很好的客户服务意识；
6．具有良好的学习能力.自我驱动能力和执行能力；以及获得结果的能力。

内网开发工程师
工作地点：杭州
招聘人数：2人
职位描述：
1．公司内部网站和工作流程开发和维护；
2．公司办公信息系统开发和维护。
任职要求：
1．计算机相关专业毕业；
2．对办公信息化建设.Java或PHP等开发语言有较好的基础和浓厚的兴趣；
3．具有良好的快速学习能力和沟通能力；具有很好的客户服务意识。

大规模网站监控工程师
工作地点：杭州
招聘人数：3人
职位描述：
1．支付宝网站业务和底层系统的运行健康状态监控；及时发现问题并有效协助处理；
2．支付宝网站运行事件记录.跟踪.总结；并出具准确的运行或故障报告；
3．对网站运行进行统计.分析；发现潜在的问题或趋势；并推动解决；
4．负责监控系统日常运行维护；完善运行监控体系。
任职要求：
1．计算机或电子商务相关专业；
2．对Linux操作系统；TCP/IP；Apache.Jboss等WEB应用具有浓厚的兴趣或钻研精神；
3．具有良好的系统化思维.问题分析与解决能力；具有良好Troubleshooting技能；
4．具有超强的学习能力和良好的自我驱动能力；
5．具有良好的职业素养；工作认真.负责；团队合作意识强；
6．能够吃苦耐劳；接受7×24的轮班值班。

数据挖掘工程师：
工作地点：杭州
招聘人数：2人
职位描述：
深入分析海量数据；发现用户行为特征；为决策分析和精准化客户营销提供方案，
构建数据挖掘模型或算法；解决实际数据分析中的业务问题；推动相关数据应用不断发展。
任职要求：
1. 良好的逻辑分析能力；对数据敏感；善于从复杂问题或数据背后发现答案；
2. 熟悉数据挖掘原理和方法；掌握一种以上的数据处理和挖掘分析软件；如SAS.SPSS等；
3. 熟悉主流数据库应用；能够熟练编写SQL代码；
4. 熟悉计算机程序开发；至少能够熟练运用一种编程语言；如C/C++或JAVA等；
5. 良好的团队协作意识及沟通能力；勇于在压力下主动承担责任。

前端开发工程师
工作地点：杭州
招聘人数：12名

职位描述：
1．负责产品设计的前端代码开发工作；产出原型；配合完成后端数据的接口；
2．解决不同浏览器及不同版本的兼容性问题；
3．负责对产品页面性能的优化和维护；
4．充分参与设计；给出前端技术解决方案并实现交互原型。
任职要求：
1．喜欢手写HTML/CSS/JavaScript/ActionScript 代码；了解web标准；
2．追求华丽高效的前端代码；了解可用性.可访问性的基本原则；有服务器端脚本语言
的实战经验；
3．平时爱好web标准；对互联网的新鲜事物.web服务密切关注；
4．熟练使用Firefox Firebug调试Web页面；熟练运用常见框架；如YUI/jQuery等。

无线支付
产品经理
工作地点：杭州
招聘人数：4名
职位描述：
1.负责移动互联网支付市场和用户需求研究；
2.负责移动支付产品规划；
3.负责移动终端产品设计；
4.持续产品优化，跟进产品生命周期。
任职要求：
1.计算机、数学或相关专业毕业，大学本科学历及以上；
2.敏锐的洞察力、分析判断能力和创新能力；
3.良好的沟通能力、团队协作和创新精神，以及抗压能力；
4.对Android、iOS 、Symbian等平台技术有了解者优先。

手机开发工程师（C++）
工作地点：杭州
招聘人数：2名
职位描述：
1. 按USECASE进行进行软件详细设计和编码实现，确保安全、质量和性能；
2. 维护和升级现有软件产品，快速定位并修复现有软件缺陷。
任职要求：
1. 计算机、数学、电子或相关专业，大学本科学历及以上；
2. 扎实的C++编程功底，深刻理解数据结构知识，丰富的程序设计经验；
3. 熟悉各种智能手机OS平台，如symbian、winmobile、linux等等
4. 有解决问题、钻研新技术的兴趣和能力,善于交流和表达,有良好的团队合作精神；
5. 喜爱手机应用，玩机一族。

J2EE开发工程师
工作地点：杭州
招聘人数：4名
职位描述：
1. 按产品需求进行进行软件设计和编码实现，确保安全、质量和性能；
2. 维护和升级现有软件产品，快速定位并修复现有软件缺陷。
任职要求:
1. 计算机、数学、电子或相关专业，大学本科学历及以上；
2. 熟练掌握Java EE技术， 包括Servlet/JSP、JDBC、EJB、JMS、Web Service
等，对各种开源的软件如Spring、Struts、Tomcat等有一定了解；
3. 熟悉面向对象的分析和设计技术，包括设计模式、UML建模等；
4.有解决问题、钻研新技术的兴趣和能力,善于交流和表达,有良好的团队合作精神。

商户事业部
培训专员
工作地点：杭州
招聘人数：2人
职位描述：
1.负责商户合作部部门成员内部培训的相关策划、组织和开展工作；
2.商户培训资料的收集、制作和整理；
3.参与外部商户在线培训平台的建立工作；
4.参与部分外部商户上门培训的工作。
任职要求:
1.了解支付宝的相关产品，熟练掌握者优先；
2.乐观开朗，勇于接受挑战，抗压能力强；
3.对培训工作富于热情，具有团队协作精神；
4.能够熟练操作office；
5.具有培训经历者优先。

数据分析师—数据挖掘方向
工作地点：杭州
招聘人数：2人
职位描述：
1、对海量业务数据进行分析挖掘，产出有效的模型供业务部门数据化运营使用；
2、相关方向包括：用户行为和生命周期相关，风险控制相关，模型架构相关；
3、熟练的sql语句编写能力，熟练oracle数据库客户端软件使用；
任职要求：
1、数学、统计、计算机等相关专业硕士及以上学历；
2、具有深厚的统计学、数学、数据挖掘等相关知识，熟悉数据仓库和数据挖掘的相关技术；
3、精通一种及以上数据挖掘工具（精通开源数据挖掘软件者优先），具有海量数据挖掘、分析相关项目实施经验，参加过完整的数据挖掘项目并有成功案例；有网站用户行为研究和文本挖掘经验尤佳；
4、思维敏捷，良好的逻辑分析能力、良好的沟通及组织能力，能在一定压力下工作。

技术支持
工作地点：北京、上海、深圳
招聘人数：3人
职位描述：
1.负责参与商务的对外合作谈判，协助商务了解合作行业模式和商业模式，针对现有业务流程给出可实现技术方案；
2.通过日常客户接触和谈判，收集和分析客户需求，整理形成文案，帮助公司改进产品；
3.协调商户合作部们和产品部门的工作，加强沟通；
4.对新产品，编写好用例代码，并且维护好其使用文档。
任职要求：
1.网络编程专业毕业，熟练asp, php, c# 或者 VB, java 任意一种；
2.愿意加入创业团队，能承受较大的工作压力；
3.经常编写网站程序或者页面，有网站开发经验者优先。

商户支持专员
工作地点：杭州
招聘人数：5人
职位描述
1.负责配合行业策略执行的相关支持工作；
2.负责行业重点商户的审核、准入和联系工作；
3.负责产品部门制度制定、执行和维护工作。
任职要求：
1.大学本科以上学历，计算机、电子商务、财务等专业优先考虑；
2.学习能力强，具有创新精神，对于电子商务、在线支付有浓厚的兴趣；
3.善于沟通，具有良好的服务意识和团队协作意识，责任心强，能承受较大工作压力；
4.熟练使用各类office办公软件。

用户事业部
运营专员
工作地点：杭州
招聘人数：3人
职位描述：
1． 分析支付宝会员特征，根据会员特征进行会员系分和会员运营；
2． 分析互联网金融类应用，结合支付宝特点创新金融类产品或服务；
3． 负责支付宝重点产品、重点频道的运营工作。
任职要求：
1．重点大学本科或以上学历，硕士优先（金融类、管理类、经济类专业），学习成绩优异；
2．较强的学习能力和逻辑分析能力，并具强烈的责任心，主动性和团队合作精神；
3．性格外向，优秀的沟通和语言表达能力；
4．对互联网业务有深入的了解；
5．良好的英文读写能力，能熟练查找、阅读和理解英语文献。

二、 岗位描述
岗位：采购与资产管理员
人数：2人
工作地点：杭州
岗位职责：
1、 负责预算编制文案工作，以及预算执行、跟踪、分析；
2、 根据预算和业务要求，进行采购审核、提请、跟踪和管理；
3、 负责网站运行资产、设备管理，包括采购验收、入库、启用、维保、下线、报废等资产生命周期管理；
4、 负责采购、资产管理相关制度的修改、完善，流程的完善；
5、 负责资产设备成本分析和管理，有效控制资产成本。
岗位要求：
1、 熟悉Office使用，具有较好的文档能力，具有IT设备采购、资产管理工作经验的优先；
2、 具有良好的沟通能力、快速学习能力和合作能力；
3、 工作细致、认真，能吃苦耐劳。

岗位：研发与测试环境管理工程师
人数：3人
工作地点：杭州/上海
岗位职责：
1、 负责支付宝研发与测试环境建设、维护、支持和管理；
2、 负责支付宝稳定测试环境的维护和联调支持工作。
岗位要求：
1、 本科以上学历，计算机或者相关专业，具有研发、测试相关经验者优先；
2、 熟悉WEB相关技术，包括Apache，PHP，Jboss等应用的管理、配置；
3、 了解Linux以及主要Unix网络服务，了解网络基本技术；
4、 了解Java应用开发，了解Shell或Perl编程尤佳；
5、 优秀的沟通能力，出色的学习与钻研能力，良好的问题分析与解决能力。

岗位：网站运行监控工程师
人数：3人
工作地点：杭州
岗位职责：
1、 负责支付宝网站业务和底层系统的运行健康状态监控，及时发现问题并有效协助处理；
2、 负责支付宝网站运行事件记录、跟踪、总结，并出具准确的运行或故障报告；
3、 对网站运行进行统计、分析，发现潜在的问题或趋势，并推动解决；
4、 负责监控系统日常运行维护，完善运行监控体系。
岗位要求：
1、 计算机或电子商务相关专业，有网站监控、研发测试相关工作经验优先
2、 熟悉Unix、Linux操作系统的使用，了解Apache、Jboss等Web应用服务器维护，了解脚本编写和开发；
3、 具有良好的职业素养，工作认真、负责，团队合作意识强；
4、 具有良好的学习能力和自我驱动能力；
5、 能够吃苦耐劳，接受7×24的轮班值班。

岗位：应用运维工程师
人数：3人
工作地点：杭州/上海
岗位职责：
1、 支付宝网站应用的部署规划、实施、维护和优化；
2、 参与支付宝网站应用产品研发，熟悉业务并给出稳定性要求和方案等；
岗位要求：
1、 本科以上学历，计算机或者相关专业，具有网站应用开发或维护经验者优先；
2、 熟悉WEB相关技术，包括Apache，PHP，Jboss等应用的管理、配置和优化；
3、 了解Linux以及主要Unix网络服务，了解网络基本技术；
4、 熟悉Java应用开发，精通和灵活运用两种以上的脚本语言，包括：Shell、Perl等，尤佳；
5、 优秀的沟通能力，出色的学习与钻研能力，良好的问题分析与解决能力。

岗位：技术服务台工程师
人数：1人
工作地点：杭州/上海
岗位职责：
1、 负责网站系统故障和问题的记录、跟踪、解决和关闭；
2、 协调重大故障处理、分析和总结报告，跟踪、推进落实相应改善措施；
3、 针对故障以及网站维护等重大事件进行业务影响分析，并进行影响预警或通告；
4、 对故障和问题进行统计分析，提出改进方案和建议。
岗位要求：
1、 计算机或电子商务相关专业，有客户服务、技术支持相关工作经验优先
2、 熟悉支付宝网站业务，具有一定的计算机系统运行基础知识；
3、 具有良好的系统化思维，良好的问题分析与解决能力；
4、 优秀的沟通和协调能力，行动以结果为导向，具有很好的客户服务意识；
5、 具有良好的学习能力和自我驱动能力。。

岗位：行为审计专员
人数：1人
工作地点：杭州
岗位职责：
1、 对线上系统中关键操作日志进行监督检查和审计，且完成日常报表分析统计；
2、 对权限进行规范化管理，且制定并更新运行管理人员操作风险控制策略；
3、 对日常规章制度进行审核，对安全流程及策略进行优化；
4、 协助主管完成其他内部控制工作。
岗位要求：
1、 思路清晰，具备敏锐的风险意识和良好的风险识别能力；
2、 有强烈的责任心，工作积极主动，乐于从事日常事务性工作，
3、 具备优秀的团队合作精神，良好的沟通、表达能力；
4、 有独立判断问题能力，有较强的分析问题及提出解决建议方案的能力；
5、 有客户服务经验者优先。

Mark一下。

By default, the key cache management system uses a simple LRU strategy for choosing key cache blocks to be evicted, but it also supports a more sophisticated method called the midpoint insertion strategy.

Key Cache管理系统默认使用LRU策略来选择丢弃的block，它同样支持一种更复杂的方法：midpoint insertion strategy。

When using the midpoint insertion strategy, the LRU chain is divided into two parts: a hot sublist and a warm sublist. The division point between two parts is not fixed, but the key cache management system takes care that the warm part is not “too short,” always containing at least key_cache_division_limit percent of the key cache blocks. key_cache_division_limit is a component of structured key cache variables, so its value is a parameter that can be set per cache.

当使用midpoint insertion strategy策略时，LRU的链被分成两部分：hot子链和warm子链。分割点不是固定的，但是Key Cache管理系统控制着warm子链，不会让它过于短，至少是key_cache_division_limit的百分比于Key Cache的长度。key_cache_division_limit是Key Cache的系统变量，所以它可以为每个Cache设置。

When an index block is read from a table into the key cache, it is placed at the end of the warm sublist. After a certain number of hits (accesses of the block), it is promoted to the hot sublist. At present, the number of hits required to promote a block (3) is the same for all index blocks.

当一个索引块被从表中读取到Key Cache中时，它被放在warm子链的尾部。在一定数量的访问(点击)后，(其实在这之前该block已经在warm子链的开始部分了)它被提升到hot子链中。在目前来说，对该block的访问次数是所有的index blocks的总和(数字的等同)。

A block promoted into the hot sublist is placed at the end of the list. The block then circulates within this sublist. If the block stays at the beginning of the sublist for a long enough time, it is demoted to the warm sublist. This time is determined by the value of the key_cache_age_threshold component of the key cache.

 当一个block被提升到hot子链时，它是放在hot子链的尾部。然后该block开始在hot子链中循环。如果该block在hot子链的开始部分待了很长时间，它会被降到warm子链。这次决定的是key_cache_age_threshold系统变量。

The threshold value prescribes that, for a key cache containing N blocks, the block at the beginning of the hot sublist not accessed within the last N × key_cache_age_threshold / 100 hits is to be moved to the beginning of the warm sublist. It then becomes the first candidate for eviction, because blocks for replacement always are taken from the beginning of the warm sublist.

假定Key Cache中有N个blocks，临界值规定了：在hot子链开始部分的block在最近的(N × key_cache_age_threshold / 100)次访问中没有涉及的话被放回warm子链的开始部分。key_cache_age_threshold决定了频率的高低(最小值100)。然后该block成为最有可能被丢弃的，因为新的block替换就发生在warm子链的开始部分。

The midpoint insertion strategy allows you to keep more-valued blocks always in the cache. If you prefer to use the plain LRU strategy, leave the key_cache_division_limit value set to its default of 100.

midpoint insertion strategy能让你保持重要的block始终在Cache中(设置key_cache_age_threshold即可)。如果你还是想使用LRU策略，那么将key_cache_division_limit设置成默认的100

The midpoint insertion strategy helps to improve performance when execution of a query that requires an index scan effectively pushes out of the cache all the index blocks corresponding to valuable high-level B-tree nodes. To avoid this, you must use a midpoint insertion strategy with the key_cache_division_limit set to much less than 100. Then valuable frequently hit nodes are preserved in the hot sublist during an index scan operation as well.

midpoint insertion strategy帮助你提升执行全索引扫描时几乎所有的Cache(warm子链的部分)都要替换成新的B树节点的性能。为了避免对性能产生较大的影响，你必须将key_cache_division_limit设置成小于100(有效地控制其影响范围)。这样重要的经常访问的节点在全索引扫描时就被保护在hot子链中。

总结：相当于在一个LRU链上虚拟了两个链(hot和warm)，全索引扫描时不会波及全部。

To minimize disk I/O, the MyISAM storage engine exploits a strategy that is used by many database management systems. It employs a cache mechanism to keep the most frequently accessed table blocks in memory:

This section first describes the basic operation of the MyISAM key cache. Then it discusses features that improve key cache performance and that enable you to better control cache operation:

To control the size of the key cache, use the key_buffer_size system variable. If this variable is set equal to zero, no key cache is used. The key cache also is not used if the key_buffer_size value is too small to allocate the minimal number of block buffers (8).

MySQL Enterprise.  For expert advice on identifying the optimum size for key_buffer_size, subscribe to the MySQL Enterprise Monitor. See http://www.mysql.com/products/enterprise/advisors.html.

When the key cache is not operational, index files are accessed using only the native file system buffering provided by the operating system. (In other words, table index blocks are accessed using the same strategy as that employed for table data blocks.)

An index block is a contiguous unit of access to the MyISAM index files. Usually the size of an index block is equal to the size of nodes of the index B-tree. (Indexes are represented on disk using a B-tree data structure. Nodes at the bottom of the tree are leaf nodes. Nodes above the leaf nodes are nonleaf nodes.)

All block buffers in a key cache structure are the same size. This size can be equal to, greater than, or less than the size of a table index block. Usually one these two values is a multiple of the other.

When data from any table index block must be accessed, the server first checks whether it is available in some block buffer of the key cache. If it is, the server accesses data in the key cache rather than on disk. That is, it reads from the cache or writes into it rather than reading from or writing to disk. Otherwise, the server chooses a cache block buffer containing a different table index block (or blocks) and replaces the data there by a copy of required table index block. As soon as the new index block is in the cache, the index data can be accessed.

If it happens that a block selected for replacement has been modified, the block is considered “dirty.” In this case, prior to being replaced, its contents are flushed to the table index from which it came.

Usually the server follows an LRU (Least Recently Used) strategy: When choosing a block for replacement, it selects the least recently used index block. To make this choice easier, the key cache module maintains all used blocks in a special list (LRU chain) ordered by time of use. When a block is accessed, it is the most recently used and is placed at the end of the list. When blocks need to be replaced, blocks at the beginning of the list are the least recently used and become the first candidates for eviction.

译文：

为了减小disk的I/O，MyISAM的存储引擎和一般的数据库系统一样，使用了缓存机制保存经常访问的block(index block)。

• 对于索引块(index block)，Key Cache中保存了常用的索引块。
• 对于数据块(data block)，MySQL没有使用Cache，只是使用了操作系统中文件系统本身的Cache。

基本的功能机制和性能优化选项。

• 多session并发访问Cache
• 可以set up多重Key Cache，并指定一个table index给指定的Cache。

参数key_buffer_size设置为0或者过小时不使用Key Cache，也就是和数据块一样只能使用操作系统中文件系统自带的Cache。

一个索引块一般是MyISAM的索引文件的连续访问的组合。一般索引块的大小是MyISAM的索引结构中节点的大小(MyISAM的索引以BTREE结构存放)。

所有Key Cache中的block buffer是一样大的，可以大于、等于、小于索引块的大小。

当需要访问索引数据时，服务器检查是否有现成的block buffer在Key Cache中。若有，则从Key Cache中读取而不是disk上读取。也就是说，对索引的读和写均在Key Cache上(写的部分到时候要flush到disk上)。若没有，服务器将Cache中包含的不同表的索引块的block buffer替换成请求的索引块的拷贝，然后再提供读写。

当一个block被替换之前已经被修改过了，这个block就被标记为”脏”。这种情况下，在再次替换前，先将这个block flush到所属表的index文件上(在disk上)。

服务器一般使用LRU策略：当选择被替换的block时，选择最近最少使用的索引块。为了更好地实现该算法，Key Cache模块将所有的block按时间顺序放在一个list中(LRU链)，当一个block被访问时，它被放在最近最常使用的位置(即LRU链的结尾，MRU端)。当一个block需要被替换时，LRU的开头部分(LRU端)就是优先考虑的部分，没有再到MRU部分找。

原文：http://www.ningoo.net/html/2010/cap_theorem_and_eventually_consistent.html

CAP原理(CAP Theorem)

在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素：

• 一致性(Consistency)
• 可用性(Availability)
• 分区容忍性(Partition tolerance)

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

最终一致性(eventually consistent)

对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

• 因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
• “读己之所写（read-your-writes）”一致性。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
• 会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
• 单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
• 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

上述最终一致性的不同方式可以进行组合，例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看，这两者的组合，读取自己更新的数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来说，会少很多额外的烦恼。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

• N — 数据复制的份数
• W — 更新数据是需要保证写完成的节点数
• R — 读取数据的时候需要读取的节点数

如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。

如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

• 如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
• 如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突

    MyISAM存储引擎有一个系统变量concurrent_insert，专门用以控制其并发插入的行为，其值分别可以为0、1或2。

    当 concurrent_insert设置为0时，不允许并发插入。

    当concurrent_insert设置为1时，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录。这也是MySQL的默认设置。如果有空洞的话虽然不能很好的并发，但是MySQL还是可以使用INSERT DELAYED来提升插入性能(仅适用于MyISAM,MEMORY和ARCHIVE引擎)。

    当 concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录，这时MySQL允许INSERT和SELECT语句在中间没有空数据块的MyISAM表中并行运行。

    注：holes– 空洞这个概念是myisam引擎特有的,myisam在存储时数据文件是顺序的,当有删除操作时,会发生数据文件的空洞.
当有新数据插入时,先查看空洞空间能否能够插入这条数据(concurrent_insert为2时不用判断),否则插入到末端，此设置只对myisam引擎有效,innodb存储方式有自己独有的方法,不会产生数据空洞。

    那么InnoDB呢，它能不能做到INSERT和SELECT并发呢？这里有个情况说明一下，当这个InnoDB表有索引时当然可以并发(行级锁，只要不连累到，因为因为InnoDB行锁的实现是在索引项上加锁实现的，不同于Oracle的在数据块对行进行加锁，而语句写得不好连累到不相关的行都会被锁定。)，但是没有呢？

    先建立一个测试表CurrentTable(注意没有索引)：

    然后插入999条数据。

    接着显式开始事务1：执行插入操作

另一个终端上对该表进行select是可以的，这个可以理解，因为只是S锁。

但是另一个终端上进行select … for update的话就出现hanging了。

hanging

从上面的例子也能很清楚的理解(InnoDB行锁的实现是在索引项上加锁实现的)这句话。

而同样的表，我创建了基于ID的主键聚集索引以后，同样的场景，select … for update是可以顺利执行的。

而当该表使用的是MyISAM引擎时，不但select可以执行，select … for update也可以(在数据文件层面实现了新插入行和更改现有行的隔离并发执行)。

    从上面的一些只言片语中应该能感觉到是不是插入性能上MyISAM比InnoDB强呢，虽然这里是讨论的insert和select并发及锁定的机制问题。

    确实，MyISAM的插入性能优于InnoDB，具体参见这篇realzyy的博文。