Những kỹ thuật và công nghệ được sử dụng trong sản phẩm Ming

Những kỹ thuật và công nghệ được sử dụng trong sản phẩm Ming Team Ming 2 Công nghệ  Memcached(Đã được sử dụng rộng rãi trong các dự án công ty)  Redis(Phần I) Kỹ thuật  Open Authentication(Phần II)  SSO(Single Sign On)  Big4(Facebook, Yahoo, Twitter, Google) I. Redis Redis là một cách lưu trữ dữ liệu kiểu key/value, nó thực thi trên server ANSI C, redis cung cấp nhiều cách làm việc khác nhau để thực hiện một việc đơn giản : lưu trữ value(“aaa”) tới key(“redis”), trong đó với các keys chỉ hỗ trợ kiểu string thì với values sẽ hỗ trợ nhiều kiểu định dạng khác nhau như : Strings, Lists, Sets, Sortedsets(zsets), Hashes. Và mỗi một loại kiểu định dạng khác nhau sẽ có một tập hợp các command làm việc với nó như: Thêm mới, loại bỏ một phần tử trong values... khác nhau. Có thể xem Redis như là một cấu trúc dữ liệu (data structures) cấp cao trên máy server, khi một người dùng redis chỉ cần cung cấp một interface để “Abstract Data Types(kiểu dữ liệu trừu tượng)”, từ đó người dùng không phải chạy các data structures hay các thuật toán trên data structures đó mà có thể thực thi các command của data type đó. Redis is free software released under the very liberal BSD license. Written in C(C99 standard). Redis có những đặc điểm giống như Memcached như:  Lưu Key – value (Key – value store).  Tất cả data được lưu trên Memory(RAM)  Key có thể hết hạn(expire) hoặc không  Nhanh(Fast), nhẹ nhàng(light-weight) Nhưng Redis có nhiều đặc điểm, chức năng khác mạng lại lợi ích khi sử dụng và triển khai. Bao gồm:  Persistence  Multiple databases Team Ming 3  Queryable keyspace  Support for interger counters  Higher level data structures  Atomic operations  Ability to paginate lists without mutating them  Master-slave replication  Optional VM feature I.1 So sánh Redis, Memcached, Tokyo Tyrant and MySQL  Redis  Memcached  Tokyo Tyrant / Tokyo Cabinet  MySQL 5.1.40 (MyISAM)  MySQL 5.1.40 (with Innodb Plugin 1.0.4), compiled into source of MySQL  2 client boxes  All clients connecting to the server using Python  Used Python's threads to create concurrency  Each thread made 10,000 open-close connections to the server  The server was o Intel(R) Pentium(R) D CPU 3.00GHz o Fedora 10 32bit o Intel(R) Pentium(R) D CPU 3.00GHz o 2.6.27.38-170.2.113.fc10.i686 #1 SMP o 1GB RAM  Used a md5 as key and a value that was saved  Created an index on the key column of the table  Each server had SET and GET requests as a different test at same concurrency Team Ming 4 Team Ming 5 I.2. Đăc điểm của Redis I.2.1. Persistence, higher level data structures Redis lấy và nạp dữ liệu trên Memory(RAM), nhưng tại một thời điểm thì dữ liệu có thể được lưu trữ trên disk(Data in memory, but saved on disk). Có 2 kiểu persistence được supported:  Semi persistent mode (Snapshotting):  Thời gian lưu trữ data trên Memory và Disk là không đồng bộ Team Ming 6  Sau mỗi N sự thay đổi hoặc N thời gian nào đó thì data mới được lưu trữ trên disk.  Do việc lưu trữ data là không đồng bộ nên data có thể bị mất khi server gặp sự cố(restart or start)  Fully persistent mode (Append Only File)  Mỗi sự thay đổi được viết thêm vào một tệp tin. Mô hình này được gọi là “Append only file”, mỗi command nhận sự thay đổi thì được viết thêm vào file có định dạng là ASAP.  Những command này sẽ được chạy lại khi server restart hoặc start để nạp lại dữ liệu lên memory. I.2.2. Multiple databases và Data structures Điểm khác biệt dễ nhận thấy của Redis là: Key là một string nhưng value thì không giới hạn ở một string mà có thể là List, Sets, Sorted sets, .... Cấu trúc dữ liệu của Redis gồm :  Strings  String-as-integers  List of Strings  Set of Strings(unique list)  Sorted Set of Strings(ZSET) Redis hỗ trợ “Multiple database” với nhiều commands để tự động remove key từ một database tới database khác. Mặc định thì DB 0 sẽ được lựa chọn cho mỗi lần kết nối(connection), nhưng khi sử dụng lệnh SELECT(SELECT command) thì nó có thể select/create một database khác. Thao tác MOVE(MOVE operation) có thể chuyển một item từ một DB tới DB khác một cách tự động. Đó là sự khác biệt của Redis với Mysql. Với Mysql, để truy suất data từ nhiều database khác nhau thì phải tạo ra bấy nhiêu connection tới những database đó. I.2.3. Atomic Operations Redis rất nhanh trong các thao tác lấy và nạp dữ liệu do redis hỗ trợ nhiều lệnh mang tính chất chuyên biệt như: Team Ming 7  LPUSH/PPUSH: Thêm vào đầu/cuối của danh sách.  LPOP/RPOP: Return và remove phần tử ở đầu/cuối của danh sách.  RPOPLPUSH: Return và remove phần tử cuối của source list và đẩy vào đầu của destination list  GETSET: Nạp một key với một giá trị mới và trả về giá trị cũ.  MGET/MSET: Lấy/nạp nhiều key với nhiều data.  SMOVE: Chuyển một value từ one set to another.  ….. Rất nhiều tính năng ưu việt và chuyện biệt nữa được redis hỗ trợ. I.2.4. Replication Redis hỗ trợ mở rộng master-slave nếu chúng ta muốn sự an toàn hoặc mở rộng, co giãn trong việc lưu trữ data.  Slaves can be used for scalability or redundancy  Một master có thể có nhiều slave  Slaves có thể nhận nhiều kết nối của salve khác  Slave có thể kết nối lại khi bị outage I.3. Thay thế Memcached hoặc kết hợp Memcached với Redis Redis có thể thay thế được Memcache vì:  Những gì memcache làm được thì redis cũng có thể, nhưng redis có nhiều tính năng mà memcache ko thể có được.  Many databases from a single instance of Redis  Có thể backup dữ liệu trên redis khi server đang hoạt động: Khi Redis lưu DB nó tạo ra một tập tin tạm thời, sau đó đổi tên (2) tên tập tin tạm thời với tên file đích. Có thể sử dụng master-slave để nhân rộng cơ sở dự liệu dự phòng  Watch live commands on a running instance with the MONITOR command  Có thể sử dụng redis như là một database, queue, server cache hoặc tất cả các kết hợp. Team Ming 8 Redis và Memcache đều có ưu nhược điểm riêng, nhưng nếu kết hợp được Redis và Memcache song hành trong công việc thì đó là một điều lý tưởng. I.4. Redis nhanh như thía nào?(How fast is Redis) Redis có tiện tích “redis-benchmark” được thực hiện với bộ mô phỏng gồm N clients trong cùng một thời điểm gửi M yêu cầu. Dưới đây là kết quả của redis-benchmark:  50 Client thực hiện đồng thời với 100.000 request.  Thực hiện SET và GET một String có kích thước 256 bytes. About 110.000 SETs per second About 81.000 GETs per second. ====== SET ====== 100.007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 58.50% <= 0 milliseconds 99.17% <= 1 milliseconds 99.58% <= 2 milliseconds 99.85% <= 3 milliseconds 99.90% <= 6 milliseconds 100.00% <= 9 milliseconds 114.293.71 requests per second ====== GET ====== 100.000 requests completed in 1.23 seconds 50 parallel clients 3 bytes payload keep alive: 1 Team Ming 9 43.12% <= 0 milliseconds 96.82% <= 1 milliseconds 98.62% <= 2 milliseconds 100.00% <= 3 milliseconds 81.234.77 requests per second II. Open Authentication(OAuth) II.1 Giới thiệu OAuth là một protocol cho phép user cấp phép cho một web application truy cập thông tin của mình trên một site khác mà không cần cung cấp thông tin login cho web application đó. Còn OpenID cho phép user sử dụng một account đã có ở một web site hỗ trợ như Google, Yahoo!, MySpace, ... để login vào một web site khác. II.2 Tại sao dùng OAuth II.2.1 Nhu cầu người dùng Người dùng không muốn nhớ nhiều username/password II.2.2 Nhu cầu chia sẻ tài nguyên – mở rộng Người dùng có nhiều kiểu tài nguyên nằm trên trang xã hội: Thông tin cơ bản, thông tin mật, các mối quan hệ, các hành động(activities) của bản thân và bạn bè. Một trang xã hội không tự mình làm hết các dịch vụ Ngược lại dịch vụ đứng một mình sẽ không tận dụng thông tin sẵn có Sinh ra các ứng dụng(apps) kết nối trang xã hội. Mỗi app chỉ nên có quyền truy cập giới hạn loại tài nguyên Ví dụ  App in ảnh chỉ được truy cập album ảnh của người dùng, không lấy thông tin về activities bản thân hay thông tin bạn bè.  Chìa khóa xe Mercedes, có chìa phụ cho lái xe chỉ có thể khởi động xe, không mở được cốp hay ngăn an toàn. Team Ming 10 II.3 Đặc tả OAuth 1.0( II.3.1 Các khái niệm service provider - SP: Nơi cung cấp dịch vụ OAuth consumer/app: Bhách hàng sử dụng dịch vụ OAuth user: người dùng request_token: Bộ khóa(key & secret) khở tạo phiên làm việc giữa consumer và SP access_token: Bộ khóa(key & secret) consumer dùng để lấy thông tin(tài nguyên) của người dùng ở SP oauth_key: Khóa định danh oauth_secret: Mã bảo mật consumer_key: Khóa định danh app consumer_secret: Mã bảo mật app callback: Đường dẫn trả về site consumer II.3.2 Luồng sơ lược SP và Consumer thống nhất bộ consumer_key và consumer_secret 1. Consumer – Service Provider  Consumer sử dụng định danh consumer gửi yêu cầu lấy request_token tới SP, báo một phiên làm việc bắt đầu.  SP kiểm tra định danh consumer, trả lại request_token ngẫu nhiên (oauth_key, oauth_secret). 2. Consumer – user  Consumer chuyển người dùng tới trang đăng nhập của SP 3. User - SP  User đăng nhập bằng tài khoản của mình ở SP với thông báo cho phép dịch vụ consumer lấy thông tin.  Người dùng tiếp theo sẽ được chuyển về trang đợi sẵn của consumer (callback) với mã oauth_verifier(SP sinh ngẫu nhiên) chứng nhận rằng người dùng đã (đăng nhập và) đồng ý chia sẻ thông tin. Team Ming 11 4. Consumer-SP  Tiếp theo bước 3 thì SP gửi về cho consumer một mã gọi là oauth_verifier để thông báo cho Consumer biết là user đã đăng nhập xong trên SP.  Consumer gửi yêu cầu lấy access_token, sử dụng các định danh consumer, request_token và oauth_verifier để chứng thực. Lúc này, consumer sẽ phải gửi lại oauth_verifier để thông báo cho SP là consumer đã nhận được thông báo “user đã đăng nhập trên SP”.  SP kiểm tra, trả về cho consumer access_token có sẵn trong hệ thống hoặc tạo mới. 5. Consumer-SP  Với các api SP cung cấp, consumer sử dụng bộ thông tin định danh consumer (key và secret) và access_token gửi yêu cầu tới SP lấy thông tin người dung cần thiết. Dưới đây là hình vẽ mô tả luồng OAuth trên: Team Ming 12 II.4 OAuth server ở Ming Đã hoàn tất đầy đủ các bước theo đặc tả 1.0  Dễ dàng cho bên thứ ba phát triển consumer Sử dụng công cụ chứng thực an toàn là chữ ký  Secret được giữ kín  An ninh bảo đảm trên đường non-https  Nonce duy nhất ứng với mỗi request kèm theo timestamp, không bị giả mạo request dù xảy ra trường hợp bị xâm nhập trái phép trước đó.  Thống nhất quy chuẩn chữ ký, do đặc tả oauth mới phát triển, mỗi thư viện sử dụng có lỗi nhỏ khác nhau: thư viện php mã hóa đường dẫn 2 Team Ming 13 lần, thư viện c# thiếu những param định nghĩa thêm… Vấn đề gây nhiều lỗi nhất trong quá trình thực hiện OAuth. “One of the most frustrating things about working with OAuth is getting back an error that the signature is invalid” ( “The signature base string is often the most difficult part of OAuth for newcomers to construct.” ( Xác thực domain  Mã xác thực đã đăng nhập SP chỉ trả về trang callback nằm trên domain consumer đã đăng ký.